Teams that take the Product Backlog seriously are more effective, which means paying more attention to the backlog and collectively ensuring a common understanding of:
- What is required?
- why is being done?
- when it needs to be delivered?
In this blog, I’ll explore ideas presented by Mike Cohn from Mountain Goat Software, about getting teams to write better User Stories. Better stories, in turn, result in clearer stakeholder communications and smaller, well defined sprint deliverables.
Conduct a Quarterly Story Writing Workshop
Prior to the workshop, it’s imperative that the Team is given a prioritized significant objectives from leadership (e.g. Stakeholders), that are possible to be completed within a Quarter and significant enough to provide real value to the organization. Once objectives are established, the entire Team (i.e. Product Owner, Scrum Masters, Development Team, etc.) comes together to review and develop the underlying User Stories. This session should take about 1-3 hours to complete, as less than an hour suggests the object wasn’t big enough and greater than 3 hours is too much. This can start with a “Big Rock” story map to define the larger components that can be refined to user stories that are detailed enough for the development team to get started. Once stories are defined, the entire list is consolidated into a Story Map, which provides a visualization of the User Stories, along with any technical / operational stories that may need to be added for support. When the workshop is complete, everyone is aligned with the objectives and understands the work. It’s important to note that perfect stories are not the goal, as a story can always use refinement, however if we get the story to contain enough information for the developers and they have the right context, we should get the desired result. In the event that additional required functionality is determined at a later date, we add it to the Product Backlog and complete the work.
Story Map Example
Workshop Outcome Deliverables
- Significant Objectives for the Quarter (Approved By Stakeholders)
- A Product Backlog that contains the initial set of User, Technical and Operational Stories to achieve the Objectives
- A Story Map that visually depicts the Stories that will achieve the Objectives
Master the Art of Splitting Stories
User Stories are a great tool, as they represent an objective way to measure progress (i.e. Not Started, In Progress, Done) and provide a mechanism for delivering “potentially shippable” software. The problem is Teams look at “potentially shippable” as “ready for market”, which leads to story commitments that are not realistic for the timeframe, thus over committing sprint deliverables. Two ways we can reduce big stories into something that is achievable within an iteration are:
- Splitting by Interface – Pretend we are building a website that allows you to search for Homes for Sale. The work entails both interface and database work. One way to spilt this work is to deliver a small number of fields, including the database components, in each iteration fully built, tested and deployed. With each iteration, more fields are added and the laws of continuous improvement are applied to deliver an application that meets the objectives.
- Splitting by Component/Rules – We are building an Algorithm that has many inputs to calculate a single output. Some of these inputs are simple and can easily be accomplished, some require dedicated effort and a few are extremely complex. In this case, a strategy may be to initially create placeholders (e.g. fixed values) for each of these inputs and develop the automated test cases, then, with each iteration, complete the delivery of inputs. Some may require multiple sprints to complete, but the end result is an output that is predictable and that will improve with each iteration.
Strive to add Just enough Detail, Just in Time
The desire to have all requirements fleshed out prior to development is strong, however trying to create the perfect User Story can result in delayed deliverables and analysis paralysis. In contrast, having too little information that is provided too late in the iteration cycle results in deliverables that do not meet the user’s needs. Mike Cohn advises that if you’re going to sin, “err on the side of too little too late.” which embraces one of the key principles of Agile, which is “Responding to change over following a plan”. This could result in additional stories being built to address any new functionality. To help with this approach, during the Workshop, as well as story refinement, we need to ask “Do you need the answer before you start the story?”, which dictates the criticality of the response. Additionally, at each retrospective, we need to ask “Did we get the answers just in time in just enough detail?”, which in turn give us guidance going forward in future sprints.
Summary
In summary, as was stated at the beginning of this that team that invests the time in planning up front what they want to build over the long haul and why are more successful that the ones that are only planning 2 weeks ahead. Hopefully this content has provided you with something to consider as you move forward in your projects.
