This picture is from the ever-useful Standish report (aka Chaos report.)
It indicates how many deliverred features were used - ranging from always to never.
How many of the requirements in your specification/backlog are going to contribute to the orange or red sectors? And how do useless (?) requirements get into systems when the same report tells us that many important features are never implemented?
A question for the experienced guys and gals reading this site - do you have some tips on how to manage this problem?
6 Comments:
Subscribe to:
Post Comments (Atom)
Posts
Well talking about dealing with the problem I don't have a good answer. I guess the most obvious way is coaching customers. However that's always tricky and rarely successful so it's hard to consider it as an answer.
In big organizations decision-makers when it comes to feature range are recruited from marketing and/or business units. Very often they don't really know what their users want since they're filtered from real user requirements by tons of analysis, surveys and guesses.
Decision about features often are made on "I think I'd like it so let's have it in the solution" way of thinking which also contribute in mentioned statistics.
Starting with Capabilities Based Planning, each requirement has a business or operational reason, and each capability has a requirements that enables it produce the planned business value.
Thsi approach is not directly applicable to "emerging" systems like an internal IT product.
But an incremental approach can be used there as well. Rolling Waves of capabilties and their requirements can be used to bound the "emergence."
But talking about solutions, here's what has worked for me, always.
Demonstrate to your customers that what they are saying (requirements) is heard and implemented by frequently releasing (or at least showcasing the application).
The customers need to feel confident about two things:
1. My requirements get implemented
2. I can make reasonable changes to the requirements.
If your customers feel that these 3 months (requirements & analysis phase) is the only time they will get to voice their requirements, they will come up with as many as they can think of. Many of which could be of no practical use to the majority of users.
Once your customers are confident about these 2 things, you can get into real de-scoping sessions. The backlog will get prioritized much better and you'll have the most useful features bubbling up to the top.
(part 1 of 6)
http://www.cleverworkarounds.com/2009/02/12/the-one-best-practice-to-rule-them-all-part-1/
This method is rooted in sensemaking but is very effective for me and really gets the participants engaged.