Setting user-story priorities is hard work. Defining the sequence or order in which work gets done is even harder. Priorities are not enough. Want to be more agile? You need to manage the order in which work gets done — sprint by sprint.
Here’s the problem. Take an agile software development team using Scrum, Kanban, Lean or XP. The Product Owner does a good job of prioritizing user stories. Let’s say she uses a standard technique such as:
- Must Have: an essential story
- Should Have: an important story
- Could Have: a desired story
(I’m over-simplifying but you get the idea. We have three priority levels and every story is assigned one — and only one — of those levels. Makes sense, right?)
On an enterprise-scale project, the team will have dozens of user stories. That means each priority level will include many stories. How does the team decide what to work on next — as in today? In a perfect world, priority wouldn’t matter. All the work would get done by the target end date. Sadly, the world’s not perfect and some stories, including some “must have” stories, will not make the final deliverable.
Making this effort even harder is the issue of complexity. There is no correlation between priority and complexity — none. A “must have” story could be far too complex to even consider including in the current time frame while a “could have” story might be simple and easily included.
What should we work on next?
The team could work through the “must have” stories sprint by sprint and then proceed to the “should have” stories, etc. That approach might work though it’s likely to be inefficient. Here’s one reason why. User stories never align with software modules. Stories can (and should) cut across multiple software modules. It’s good programming practice to group stories that touch common software modules so the team is focused on particular areas of the code. Teamwork improves and testing is easier.
If team efficiency (i.e. productivity and cost) is important to the company, user stories will not be implemented in a strict priority fashion. There needs to be a story order that considers other factors affecting the team’s ability to deliver. Establishing order has to be a team activity. It’s not easy and it will change from sprint to sprint.
Priority tells us the importance of the story to the business. Hopefully, business value was a factor in determining priority. Here’s a short list of additional factors to consider when determining story order:
- Complexity of the user story
- Availability of the right person to work on it
- Code status: new code versus changes to existing code
- Location of the new code within the system
- Risk level (likelihood of breaking the build)
Having trouble ordering all your stories? Maybe you have too many. Try saying ‘Won’t have’ to some of those user requests. In other words, that story won’t make the deadline.