
Estimation Essentials – Does it fit in a Sprint?
What do you do if work is too large to fit into a Sprint?
The User Story format originates from Extreme Progamming (XP). It is just one of many ways to write, define, and communicate Product Backlog items. Learning all of these formats will assist you in communicating:
Scrum uses the more generic term “Product Backlog item” to describe the items of work in the Product Backlog. Importantly, Scrum is agnostic of the format used to describe those items. Teams are free to use the User Story format, the Three Cs, or even INVEST.
SAFe® uses Stories to describe the items of work at a team level, Features at an Agile Release Train (program level), and Epics at the portfolio level. Overall, SAFe® has 9 different types of ways to write backlog items in their requirements model depending if they backlog item is defined at the portfolio, Agile Release Train, or team-level.
In XP, User Stories serve the same purpose as use cases, but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are typically written by the XP Customer as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.
User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.
One of the biggest misunderstandings with User Stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the Story, developers will go to the XP Customer and receive a detailed description of the requirements face-to-face.
Another difference between stories and a requirements document is a focus on user’s needs. Avoid details of specific technology, data base layout, and algorithms. Instead, keep stories focused on user needs and benefits as opposed to specifying the technology solution.
What do you do if work is too large to fit into a Sprint?
Creating a baseline for estimation speeds up estimation and makes it more accurate.
How do you slice Product Backlog items so that they can be delivered in a single
Big stories can causes lots of problems. The remedy is to slice the item into ‘small’
One of the easiest methods to slice Backlog items into smaller pieces
How do you slice Product Backlog items so that they can be delivered in a single
How do you stop Stories from “rolling” over to the next Sprint?
The three Cs format is the simplest way for teams to turn traditional requirements into good
When a Story doesn’t get finished by the end of the Sprint, what happens to it,
The Story format helps teams focus on the customer and their context to deliver value to
Extreme Programming (2009): A gentle introduction. http://www.extremeprogramming.org/rules/userstories.html
Scaled Agile Inc (2022) SAFe Requirements Model. https://www.scaledagileframework.com/safe-requirements-model/
All fields are required.