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.
I drew this picture with Corey Haines at the Krakow April 2011 Code Retreat. I started with the overall silhouette of the method, and Corey added the eye and the comment. In the end, I think we got an excellent motivational poster. So, developers, don’t let your methods look like this!
The right bottom corner is about another thing you should remember: at least know the name of your pair before starting to program. It’s funny how many times I’ve seen developers jumping right into the problem and forget this simple thing.
In the end, many thanks to the people who made the Code Retreat Krakow such an amazing experience. Pair facilitating with Corey is always an awesome experience, and I’d love to do it more often. I loved the energy of the participants and I’m really proud of the T-Shirt. Corey, Krakow, see you again soon!