A prioritized backlog is the backbone of an Agile project.
You may have conducted a three Sprint Workshop on stories that are targeted toward a government program manager or may have used a simple exercise as practice. Now you will create stories and a prioritized backlog that are targeted at your own program. This is no longer an exercise so let’s get to work!
- Two hours for workshop (full team, including customer representatives)
- Two hours of preparation (Agile Project Manager and Product Owner)
Your preference of tools for the backlog: sticky notes, Trello, etc.
An estimated, prioritized backlog of stories available to the entire team. The backlog is created by engineers but prioritized by the customers.
Can your entire team see the backlog? Is there a general consensus that tasks will result in a useful functionality to the customer? Are the stories reasonably clear and in the standard format?
To begin your first full sprint, your team needs a fully prioritized and estimated backlog with enough stories to make several sprints’ worth of stories that will provide actual value to your users. Given the experience in story writing, estimating, and sprinting in the previous workshops, you have all the knowledge you need to make a fully prioritized and estimated backlog for the beginning of your real Agile project. As a government employee, you have the opportunity to make a greater impact with your project than many commercial firms ever hope to have. This is a is a good time to review the Agile Manifesto.
Remember, Agile processes are designed to help you serve your purpose, not to get in your way. However, most people have found that following Agile processes as taught in this course allows you to produce software faster, with less risk, and with infinitely better customer satisfaction than older methods.
Choose the project that you will use for your first sprint and gather your Product Owner, designers, writers, and any other customer-facing stakeholders that will be important for identifying stories, along with your development team.
Drawing on what you learned from the User Story workshop, you will create your user stories and estimate them in preparation for your first sprint planning meeting. The format is the same as for the User Story workshop, but in this case you will have more time on the stories and will be more practiced at estimating.
Workshop Phases: 2 hrs
- High level overview: 5 min
- Review of INVEST mnemonic: 5 min
- Writing of user stories: 30 min
- Backlog grouping exercise: 15 min
- Backlog prioritization exercise: 5 min
- Quick estimation: 60 sec per story, up to 30 min
- Reprioritization: 5 min
- Format checking: 5 min
- INVEST checking: 5 minutes
High level overview of the project vision
The Product Owner will tell the team about the high level vision for this project to set the scene for creating user stories that will meet project goals.
Review of the INVEST mnemonic
The Agile Project Manager will give a brief introduction to the story format and the INVEST acronym, which are ideally written on a flip-chart or somewhere where everyone can see them.
Writing of User Stories
Everybody takes a sharpie and cards. Everybody writes stories that they think advance the project goal. The Agile Project Manager and Product Owner should walk around answering questions during this time. People “publish” their stories on the wall or table as soon as they are written, but no criticism of stories is allowed during this phase.
Backlog grouping exercise
All the cards are presented to the whole group. Stories that are duplicates or very closely overlapping are grouped together. Note that upon reading the stories of others, anyone may write new stories (and in fact this should be encouraged during any phase). If a story is consensually deemed to be obsolete or going in the wrong direction, it can be thrown away or moved into a reserve pile. During this time stories can be rewritten or reworded to make them more Independent.
Backlog prioritization exercise
The stories are force-ranked into order, with the highest priorities at the top. There are no ties — a specific order must be chosen. Open discussion is allowed. In the end the Product Owner sets the actual priorities. His or her authority to do this is absolute.
The Agile Project Manager must keep the discussion to 60 seconds per story, which will be very hard. People will want to discuss the stories far more. Under no circumstances can you take more than 120 seconds on a story. If 120 seconds goes by, the development lead writes something down no matter what.
It might seem that a longer time would produce better estimates. Experience has shown that this is not true, and that quick estimates are just as good as longer estimates. If a single story is estimated to be of such effort that it exceeds a single sprint of work, split the story immediately into two or more simpler stories. It is always better to have at least 10 stories in a sprint.
Given the estimates, the stories may be reprioritized or adjusted. This is usually an important learning phase. There are often stories that are surprisingly easy or surprising hard, and given their cost, the order in which they are to be accomplished clearly changes.
Review that each story is in the correct format: “As a ____, I need a ____ in order to ____”.
Try to make sure that each story is testable by writing a description of the test on the back of the card. This should lead to a lively discussion between the developers and end-users.
- There will be many duplicate or similar user stories that can be refined while consolidating cards.
- Some stories will have estimates that are very large and may need to be separated into individual stories.
- You won’t get all the stories in this meeting to fulfill your first sprint, but you will come very close and the missing stories will be obvious as you are sprint planning.
- Estimating will be difficult so adhere to a schedule and remember that they don’t need to be exact.
- Did your team work together to build a prioritized backlog?
- Can you explain why your stories are prioritized that way?
- Congratulations, you are ready to run your first Agile project!