The general rule for prioritizing the backlog is that you do it based on business value. From the business perspective, this makes a lot of sense: you maximize the ROI by doing first the things that create the most value in the context of your product, be it monetary or non-monetary (e.g. number of visitors on the website, number of registered users etc). You define the goals during the release planning and then you make sure that you’re going in the right direction.
The second level of prioritizing happens during the sprint planning meeting. The team looks at each story and tries to see if the story is ready-ready, meaning if the Product Owner says it’s ready for the team and if the team thinks it’s ready to start. So actually the highest business value is not useful at this point anymore; instead, there’s something else.
It’s about information.
The business value is a very good indicator for which stories should the Product Owner work on next. However, the team will waste a lot of time if they start to work on stories that are not ready for development, and potentially be unable to finish them. Doing this also creates a high variation in velocity, since the learning time is different for each story.
So, when is a story ready-ready?
And the best answer I came up with until now is:
When all the questions related to “what are we doing”, except for the trivial ones, have been answered
Here are some examples of questions that you need to look for:
- Why would the user need this?
- What happens if the user does [action]?
- What if the user goes through [another screen]?
Here are some examples of trivial questions:
- What color should the button be?
- What style should the text have?
These last questions are easy to implement during the development because they need very small changes.
So, when prioritizing your backlog, take into account that you will use the information based prioritizing as well, not only the business value.