Subscribe via RSS

Quit Putting Your Solution In My Feature Request!

Filed Under Software Process

Goldfish

A timeless process anti-pattern is when customers create a feature request and completely neglect to frame it in the phrase of a problem, rather they fill in what they perceive to be the solution. I simply call these – solution requests.

So what does the anatomy of a solution request really look like? Let’s first look what a good user story might look like:

As a paid customer, I can export my daily budget numbers to a spreadsheet.

Simple and small little user story. It doesn’t exactly explain why the problem exists, but some user stories are only meant to facilitate communication so the developer can understand the problem better.

Now here is a “solution” request:

As a paid customer, I can export my daily budget numbers to a spreadsheet. This will be accomplished by putting a button on the accounts page. This spreadsheet will be in CSV format with column A being the Total number, and D32 being the sum of all numbers.

This user story sucks, and rightfully so for a number of reasons:

Implementation Expectations

Who is it that makes feature requests? CEOs, paying customers, managers…in short, people from the top.

Solution requests are a Usability Engineers nightmare. Expectations to accomplish the feature (with the proposed solution) leaves very little maneuvering room if you are not willing to fight for it. Who knows usability habits better – a designer or the secretary?

Lack of Problem Understanding

Most user stories and feature requests are purposefully left vague as to engage the developer in conversation about the problem domain and possible solutions. When a feature request already has a solution, developers never have the chance to learn the problem domain that they are developing for.

It is necessary for quality solutions that the developer eventually becomes a domain expert in the problems that the software is trying to solve.

Solution, Party of 1

Assuming you have ignored my last two bullet points and have implemented the solution request. Probability is you have a solution that only solves one persons needs.

Without understanding the true problem, nor giving thought to how other people might benefit from the feature, you have created a feature that will probably be consumed by only one person (if that).

Allowing your clients and customers to create solution requests is just another weak link in the process chain that will allow for them to overrun and manipulate your design, process, and sometimes success of a project. Nip this anti-pattern in the butt by almost sounding Alex Trebek-ish,

Can you please phrase that in a problem?

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.

Comments

3 Responses to “Quit Putting Your Solution In My Feature Request!”

  1. Tobin Harris on November 24th, 2008 2:51 am

    Yeah, I get these a lot, and it’s frustrating!

    I find that use-case authoring guidelines given in most use-case books are pretty spot on: Write use cases at goal-level rather than task-level, this lets you focus on why users what a feature. And, don’t discuss UI issues, they take the focus away from problem back and start focusing on solution.

  2. Dew Drop - November 24, 2008 | Alvin Ashcraft's Morning Dew on November 24th, 2008 7:10 am

    […] Quit Putting Your Solution in My Feature Request! (Max Pool) – Link of the Day […]

  3. Chipping the web: November 24th -- Chip’s Quips on November 24th, 2008 7:00 pm

    […] Quit Putting Your Solution In My Feature Request!"When a feature request already has a solution, developers never have the chance to learn the problem domain that they are developing for. It is necessary for quality solutions that the developer eventually becomes a domain expert in the problems that the software is trying to solve." Thanks, Arjan.Tags: requirements feature development design Tags: combinator, combinators, del.icio.us, design, development, feature, homoiconic, iteration, javascript, memoizing, programming, recursion, requirements, ruby, weblog […]

Max Pool - © 2017 - {codesqueeze}. Sycorr Banking Solutions