I’ve been leading and coaching software development teams for fifteen years, and there is one problem that has surfaced in some form in every single team I’ve ever worked with. The problem begins when the Product Owner asks the engineers to work on a vague story with very little context and no acceptance criteria. The typical pattern looks like this:
- Someone important asks for something to be done quickly
- The PO throws in a placeholder story with a brief title and description
- During sprint planning, the PO does their best to describe in a general sense what they’re looking for
- The engineers call out a number of “what if” scenarios and edge cases that weren’t thought through
- The PO provides some insufficient answers, and the story is accepted into the sprint
- A few days later, when the engineers begin working on the story, they have to go back to the PO with a litany of questions to fill in the missing details
- Throughout the sprint, they go back and forth clarifying details, working through scenarios, and trying to agree on an acceptable target for release
- By the end of the sprint, the scope of the story has drastically changed, the estimates were completely off, and the work slips into the next sprint
Sound familiar? This is called Requirements Churn. It happens when the PO doesn’t think through all the use cases or provide clear acceptance criteria, and the team doesn’t hold them accountable to a clear set of criteria to enter the sprint. The solution to this problem is having a clear Definition of Ready, not only for sprint planning, but for several gates during the grooming process.
What is Definition of Ready?
The Definition of Ready outlines the criteria a story should meet before it’s ready to move to the next phase. This article defines best practices for story grooming from the initial concept to entering a sprint. While this article describes an ideal scenario, not all items may be applicable or feasible for every story. Use your best professional judgement to determine what is needed for each story.
One thing to remember is that not all stories being groomed today need to be included in the upcoming sprint. A story can meet one grooming milestone this sprint, but may not be baked enough to enter the next grooming stage until the following sprint, and it may not be ready for sprint planning until the sprint after that. You can and should give stories their due diligence to meet each stage’s criteria, rather than trying to rush everything through to make it into the next sprint.
At a high level, a well-groomed story upon entering a sprint should follow:
INVEST Criteria for Story Acceptance:
- “I” ndependent (can be released on its own)
- “N” egotiable (not a requirements specification)
- “V” aluable (to the customer)
- “E” stimable (can be confidently pointed)
- “S” mall (so as to fit within a single sprint)
- “T” estable (in principle, even if test cases haven’t yet been defined)
Essential Elements of a Well-Groomed Story:
- Purposeful user story following: As a / I want / So that
- 1-3 important scenarios describing the story for different use cases
- 3-5 acceptance criteria following: Given / When / Then
- 1-2 examples illustrating each acceptance criteria
- The workflow diagram describing the entire flow, which links to adjacent workflows
That’s what a story should look like when it’s ready to work, but there are several review stages, or gates, where the story should be evaluated before moving on to the next stage.
Let’s look at each important stage in the grooming process, starting with the high-level Epic that encapsulates several related stories.
Epic Definition
For any significant feature that spans more than one sprint and includes multiple related stories, an Epic should be defined. The Epic is the source of truth for all relevant context and artifacts for that feature. This is where we define the purpose, business case, benefits, and goals for a feature. This is where we do our fundamental product research. As we define individual user stories, we should always refer back to the Epic for the big-picture context.
I recommend holding an Epic review with the team once a month, where you review the context and purpose of new Epics, and give updates on the scope and priority of existing Epics.
Some of the information below should be defined before the first story is written, but other details can be filled in as the feature is in flight.
A well-defined Epic should include:
- Mock Press Release describing the narrative and benefits of the intended feature
- Background and Purpose
- Customer stories, feedback, and supporting data
- User Personas
- User Journey Map
- Key Benefits
- Competitive Research
- Product metrics (how we will measure success) and Expected outcomes (what success looks like)
- Links to all sources of truth for designs, requirements, etc.
- Monitoring, alerting, and other operational requirements
First Contact with Engineers
Before an engineer looks at a story, the PO should have a clear picture of the problem that we are trying to solve. There is no talk of a solution just yet, but we should understand how the customer experiences the problem, how they’ve tried to solve it using other methods, and what success looks like. We don’t necessarily want to bring an engineer into the room when the story is too vague, but we also don’t want to leave them out until it’s too late.
The PO should review stories with engineers as soon as the story has enough context and clarity around the problem to have a meaningful discussion about the use cases and technical feasibility of a solution. The main benefits of First Contact are to clarify the problem and engage engineers in crafting the solution.
Activities Prior to First Contact:
- Stakeholder interviews
- Customer research
- Usability testing
- Epic definition
Definition of Ready for First Contact:
- Story narrative prepared illustrating the problem and explaining the goal state
- Purposeful user story following: As a / I want / So that
- Story tied to well-defined Epic
- High level workflow diagram describing the entire flow or user journey
- Supporting contextual information (customer feedback, usability videos, marked up screenshots, competitive teardowns, etc.)
- 1-3 important scenarios describing the story for different use cases
- Optional: Rough wireframes
Final Grooming Review
During the grooming phase, the PO holds several working sessions with customers and stakeholders to flesh out detailed use cases and acceptance criteria. The PO should meet with engineers early and often to identify edge cases and “what if” scenarios, which engineers are incredibly gifted at calling out.
During the final grooming review, the engineers should be able to fully conceptualize the problem and goal state, understand the complexity of a solution, and to assign story points.
Activities Prior to Final Grooming:
- PO takes feedback from engineers and fleshes out detailed use cases and acceptance criteria.
- Designers craft wireframes and detailed UX workflows
A story that’s ready for final grooming should include everything above, plus:
- All scenarios and use cases defined
- 3-5 acceptance criteria following: Given / When / Then
- 1-2 examples illustrating each acceptance criteria
- Key Non-Functional Requirements defined, including response time, data timeliness, concurrency, etc.
- User workflows defined and attached
- Wireframe designs created and attached
Sprint Planning
When a story enters sprint planning, the problem and success criteria should be completely clear to everyone on the team, dependencies mapped and resolved, and the story should be immediately ready to work.
I suggest the engineer take time to create technical subtasks that explain the general plan of attack. This may include things like “Create class/API to perform X function” or “Create database structure to store Y information”.
Activities Prior to Sprint Planning:
- PO maps out dependencies and ideally resolves them ahead of time. Otherwise, create dependent stories and plan to track them during the sprint.
- Engineers review acceptance criteria and write corresponding acceptance tests
- Engineers define technical subtasks to explain general plan of attack
A story that’s ready for sprint planning should include everything above, plus:
- User stories written and validated according to INVEST
- Dependencies defined and resolved
- All Acceptance Criteria and Non-Functional Requirements defined
- Finished designs created and attached. Note: These don’t have to be final designs for a production ready feature. They could be mockups used to develop a prototype.
- Key acceptance test cases defined and attached
- Documentation needs defined
This may all seem overwhelming, but I’ve presented this model to dozens of teams and asked the simple question “What would you take out?” While there may be some debate on when certain items should be complete, everyone agreed that all of these items are essential. So how are we supposed to manage all this work for each story?
The answer is simple: You’re doing it all anyway. You’re just doing it after the sprint begins, so that you’re causing chaos and inefficiency in the team.
Slow down. Take your time. Do less, but better. Give each story the due diligence it deserves. The time typically wasted with requirements churn will make room to do all of these activities. There may be a momentary pause to retool and fully bake the current set of stories, but once this process is in place, your product development machine will start humming.
Final Note: A picture is worth a thousand words, and a story is worth a thousand pictures. Focus less on writing detailed criteria, and more on collecting context and stories about the user experience.
If you made it this far…
You are probably struggling with delivery, and looking for help. You’re not alone.
I’ve been leading and coaching agile development teams to achieve peak productivity for over fifteen years. Over the years I’ve worked with every area of the business that affects product development, from top to bottom, and from product management to engineering and operations. I’ve come to the conclusion that the only way for an organization to succeed at scale is to have mature product leaders at the very top.
For this reason, I’ve narrowed my focus directly on the Technical Executives, CTOs and CPOs, in charge of developing and managing the product organization. As your executive coach, I will help you become the product leader that your company needs at each stage of growth. I’ve developed a methodology tailored specifically to technical executives that quickly drives maturity in yourself and your organization, and guarantees a 10x return on your investment in coaching. If you would like to chat about how I can help you get to the next level, email me at eric at fullcycleproduct.com.