I've worked with product owners or customers that complain that marking an item on the backlog as low priority instantly sends it to the graveyard to live for eternity and never return. They know that the branding, design, and usability issues on the site are cheap to fix but are not important enough to prioritize in isolation.
Solution?
When you have enough, group them together. Have a story that is "improve the experience of your sign-up process". Lump all those design, usability, and branding bugs into one story and make the team bang through them. (Of course, maybe they shouldn't have gotten through acceptance in the first place, but I needed an example and this reflects reality in a couple places I've worked.)
Another option: When the team picks work for a sprint, they pick up a few big stories and typically have a point or two of left over space. Make them pick up some cheap stuff off the bottom. Have them pick based on closeness to other stuff they are touching. Or have them pick based on value. After all, getting $10 of value for 30 seconds of work is slightly better than getting $1000 of value for over an hour of work.
This was the idea behind the first part of my comment about backlog prioritization on vikramadhiman's agile diary blog.
Hi Kevin,
ReplyDeleteI can't help but see a self-contradicting attitude in the product owner you describe: s/he actually really wants an item to be done but somehow doesn't give it an according high priority?
Either it has real value to him and then s/he must give it an according priority or it hasn't and then it only needs to be done when everything else has been.
Should I imagine that the product owner might be "ashamed" to ask for such a triviality to be done with high priority? If yes then it seems to me like a psychological issue and it might be worth addressing it directly rather than to think of a trick to do what s/he wants though s/he doesn't dare to ask for it.
What am I missing?
Erik
The product owner has listed over 100 stories the backlog, and it's the first release. To them, everything is a high priority and is desired for release.
ReplyDeleteAs the project continues, new requirements are clarified and uncovered. User feedback leads to some more. The closer the team gets to release, the more pressure to understand what is really needed.
In these cases, there are differences between what the product owner really wants (icing on the cake) and what they know is more important (the cake itself).
another article that might be helpful
ReplyDeleteHi Kevin:
ReplyDeleteSlipping in these smaller stories is important but again I think the problem is no one knows what is good priority and hence the issue. One of the teams I knew always picked up at least 05 user stories with an estimate of 01 and another 05 with an estimate of 02 as per the customers priority.
Thanks