Recently faced with the challenge of getting 136 epic stories prioritised fast with a group of stakeholders before the team started to estimate, we tried something that was new for me, using an affinity approach to prioritise.
Often that initial prioritisation of a Product Backlog can take a while as you try to assign value to each item or discuss the relative benefits of each story. However we had a team who were ready to go with estimating and we wanted some notion of priority, so that the team could focus their efforts correctly when estimating. Therefor we decided that we didn’t need business value associated with each item, that could come later, instead a prioritised list would be sufficient.
We planned to use affinity estimation to T-Shirt size the Product Backlog, so we thought why not use that kind of idea for this initial pass at prioritisation. We were able to get all 136 stories prioritised within an hour, with 5 stakeholders participating.
Here’s how it went:
The Product Owner introduced a story and placed it on a table. The next story was then introduced and he said if he thought it was higher or lower priority, if it was higher priority it was placed on the left, if it was lower priority it was placed on the right. At this point discussion would break out and an opportunity given for others to move the story. Then another story would be introduced and placed in relative priority to what was already laid out. Some stories might bob around for a while, but eventually they settled down.
We had time-boxed the activity to 1 hour and started a little late, but by the time we had a dozen or so stories the space on the table started to take on a life of its own, and now we had a baseline the pace picked up. There was now a group of high priority items on the left, some stories that people were talking about medium priority were in the middle and the low priority ones on the right. As the number of cards grew the cards started to be prioritised vertically as well as horizontally, still all relative, but such that the highest priority card was in the top left corner and then priority went down the column and then onto the next.
As we did this the interesting thing was that people started to discuss what it meant for something to be high priority, many of the Epic’s would need some part of them delivering to constitute a minimal viable product, but what made us want to prioritise something high up the list? It was good to let that come out rather than define it up front.
Starting from the left we then drew lines where we thought there was a step change in priority, and classified them as we had started to discuss as high, medium, low. If we had taken more time we could have been a bit more sophisticated and assigned relative numbers to each story representing the value. We ended the session with all 136 items prioritised, each with a unique priority, ready for the team to estimate.
Prioritisation does not end here, but this was a very fast way of getting an initial prioritisation, and it certainly helped start the conversation about Product Backlog priorities.
Final picture above is of me and the Product Owner, note the Vision, which is visible stuck to the TV above our heads.