Help for Product Owners: Prioritizing the backlog

First Things First: Prioritizing Requirements

Karl Wiegers provides some advice on the topic of prioritizing the backlog and he throws in a spreadsheet for free as well:

"Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product (at least, not if they want the features to work). However, if the development team cannot deliver every requirement by the scheduled initial delivery date, the project stakeholders must agree on which subset to implement first. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions."

You can find his spreadsheet here.

Estimations: storypoints vs hours

Refactor Your Mind » complexity

Another good posting of Tick Tonoli regarding the reoccuring topic of estimating by using abstract storypoints vs hours. I rarely managed to get the point across, maybe his explanation works better:

"During our estimation (still doing hours effort estimation) we were trying to define the tasks necessary for a story to be completed, however the story had a “task A” that would lead to several “task B’s” that were known, however no-one could (and neither should they be expected to) estimate the hours effort on the “task B’s” simply because the input from “task A” was critical to the timing! Now you’re stuck with tasks that are KNOWN, but cannot be TIMED. And then the light went on and I realized why estimation with time was so bad…You may KNOW everything you need to do (the complexity), however you may not necessarily know how LONG everything will take (the effort), in other words, you know COMPLEXITY but you cannot measure the EFFORT. It now makes sense…"

Affinity Estimation-when there are a lot of stories to be estimated

I came across Rick Tonoli`s Blog and found a couple of very interesting articles. Still working my way through his postings, i'll praise him later in a separate article after covering his and other opinions on the topic of "affinity estimation". I didnt apply it myself, but it does sound like a good approach to get a high level estimation done without wasting too much time.

He is refering to Kane Mar's blog who in return references to Jukka Lindström who posted his comment here. I would love to test it as it sounds very intuitive. A might be more suitable for a pretty senior team, but then again, what isn't...

Here is Kane Mar's comment on it:
"We started by reading out each Story to the entire team. Lowell then asked us to arrange the stories horizontally on a wall in order of size, without talking. We placed the largest stories on the left and the smallest stories on the right. This only took a few minutes. We were then given a final opportunity to make adjustments to the ordering, again without talking.
 
...
Finally, “Affinity Estimating” helps make estimating a positive experience rather than a confrontational one. The next time you have a need to estimate a large number of User Stories, consider trying “Affinity Estimating."

Sounds like it could also be an interesting tool for team(member)s that struggle to speak their mind or or have problems with confrontations. Ball-parking new projects should/could be simpler as well.

You can find a more detailed description about how it works here.