One idea that was brought up had to do with measuring value. The technique involves assigning value points to each feature or user story by the product owner. For example, the most important feature may get 10 points, some minor feature only gets one point.
As features are delivered, you track the points to show how much value is being delivered. So if you look at the graph below, you see for the first few iterations, the value goes up pretty quick but then it levels off. Since you're not delivering much value by the fourth or fifth iteration, you should consider ending the project and moving on to another project that would be adding higher value.
4 comments:
Bob,
The more fundamental problem is that much of what the team is delivering is not really valuable to the business. The team is delivering features that can ultimately be consumed, but as an entity, the story often doesn't have standalone value.
In my experience, it is only when we start talking about larger Epics or groupings of features... sometimes even the project... the the business starts to get interested assigning 'value points'.
Thanks for your post!
Mike,
I notice that Bob stated the value points are assigned by the product owner. In strict Scrum terms, that means the individual who is accountable for delivering the business value of the project is the one who assigns the value points. In a looser interpretation of the term, it can refer to whatever group(s) and mechanism(s) an organization uses to estimate the value of software features.
Bob seems to be describing a model, and not commenting on whether particular business people might or might not be "interested" at the level of individual stories. Helping them understand why they should be "interested" is a challenge in agile implementation, not a flaw in the approach.
Dan Rawsthorne's method of decomposing the larger pieces offers a practical technique to guide the product owner to the story level during planning sessions. So, I think it is a very practical way to approach this.
In fact, I've used exactly this technique, and it worked well. The product owners actually /did/ make the decision to stop spending on the current project and invest in something of higher value based on our tracking of the value points they had assigned.
Without this sort of measure, as imperfect as it may be, there is no basis for making such a decision, and the organization has no choice but to keep grinding away at the "nice-to-have" requirements even if they ultimately won't add value, and even if it means developers are occupied building low-value features while higher-value work waits for them to become available.
Mike/Dave - Thanks for the comments. One challenge I have is getting the product owner to say "that's enough" and wrap up the current release and push it to production. This technique would help with that.
Use project management software as a tool - not as a substitute for effective planning or interpersonal skills.Project Management Software
Post a Comment