The GSD Gold Approach to Story Grooming
Yay! Your Product Owner has written some Stories and you have your initial Backlog. Now, the fun begins. It’s time to meet with the rest of the team to groom and size those Stories, so they are ready to be sprint candidates.
Every GSD Gold Team Member Participates
Everyone on the development team who will pull stories from the Backlog has the right to provide input to Story size. That means the business analyst who (most likely) wrote the Story, the programmers who will develop the Story and the quality assurance testers who will confirm the Story meets the acceptance criteria all have a say.
If there are multiple teams working from the same backlog, invite all affected development teams to your grooming session. Because this is your first Story grooming session, we recommend setting aside 2-3 hours for grooming and estimating.
Early on, we instructed if the application is so large that you need to break the team into more than 2 or 3 development teams, then you should divide the application and corresponding backlog into multiple backlogs. Not only is it difficult to manage a giant backlog, it can be even harder to reach Story sizing consensus with a large group of people.
Story Points
Before we blow your mind with agile mindset stuff regarding Story points, let’s take a few minutes to get in the mood for Story point estimating.
We think like the cool agile kids.
We’ve adopted the following principles of the agile mindset.
GSD Gold Teams believe:
- High-level architecture design is a good thing because we need a development framework. This is not the Wild West.
- We don’t need to flush out every detailed requirement before we begin development.
- An application is made up of feature Epics, not subsystems.
- Feature Epics are broken down into individual components of unique functionality. We no longer think in terms of Work Breakdown Structures (WBS).
- Components are broken down into Stories that can move to Production when complete. We no longer think in terms of Tasks on a Project Plan.
- We think in terms of slices not layers.
Now that we are in the proper mindset, we are ready to add Story points to our agile thinking. After today, we no longer think in terms of hours to complete a task. We think in terms of Story points level of effort to build Story functionality.
Story points are a relative sizing method for estimating the size of a Story. The average number of Story points completed in a sprint is called the team’s Velocity.
Story points are based on the Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21 …
Each subsequent number in the sequence constitutes twice the level of effort of the previous number. Most teams that practice a 2-week sprint cadence do not take in stories larger than 8 Story points.
When the team reviews its stories during Grooming, they should compare the level of effort required to complete a Story to previously completed stories that were accurately assigned the same size. Because your team is new to agile and has no previously completed stories, start with the following GSD guidelines to size your Stories:
About 1-2 days of effort* = 1 or 2 points
About half week of effort* = 3 points
About a week of effort* = 5 points
Could take entire sprint* = 8 points
*Per developer and tester
I can hear you thinking, “That’s all fine and good ladies, but how do I work with the team to assign Story points?” Glad you asked. It’s Planning Poker time!
Planning Poker
Planning poker is a consensus-based technique for Story point estimating, and you can actually get cool planning poker decks with the Fibonacci Sequence printed on them for every member of the development team.
What’s the point of planning poker? The point is to allow each member of the team to come up with an independent relative Story point estimate of Story size.
The team reviews each Story in the Backlog ready for grooming one at a time, starting with the highest priority Story. The Product Owner or Business Analyst reads the Story out loud to the team, then asks if everyone understands the requirement.
If the requirement is not well understood by the development team, 3 things can happen:
- The Story may be updated to better describe the requirement and acceptance criteria.
- If the Story is too big, it may be broken down into smaller stories.
- The Development Team may decide the Story is too vague in its current format and request the Product Owner revisit the requirement
When everyone understands the Story, it is ready to be sized. If you are playing with cards, no one says a word as each member of the development team takes a card from the deck that represents the Story’s size and places it face down on the table. When everyone has laid down their card, the Scrum Master instructs the team to turn over their cards and raise them up, so the rest of the team can see. If you don’t have decks yet or don’t want to use them, when the team is ready, ask everyone to raise their hands using their fingers to show the number of Story points, kindda like playing Rock, Paper, Scissors.
Everyone looks around the room to see what points each person has selected. Some teams throw out the extreme high and low estimates, but we believe some insight can be gained by asking why the person picked such an extreme answer.
If there is no easily recognizable consensus, the Scrum Master facilitates a short discussion. Talk about things like:
- What tasks need to be performed to complete the Story?
- How big is the level of effort for each task?
- How many team members must work on the Story to get it done?
Then, the team picks a size. If the Story point estimates are close, like all 3’s and 5’s, just go with 5.
In GSD Gold, We Estimate Spikes
Remember those special Stories called Spikes? We talked about them in Chapter 3. Spikes are written when the team does not understand the requirement enough to write a Story and/or code a solution.
Classic agile dictates that no Story Points be assigned to Spikes. We at GSD disagree. Spikes contribute to the team’s knowledge and lead to a better overall application design. Another reason to assign Story Points to a Spike is to limit the maximum level of effort expended on the Story. That way, those working on the Spike don’t go down some rabbit hole if the issues cannot be easily resolved. A good rule of thumb is to only assign Spikes 3 or 5 points, so no more than one week is consumed by the issues it represents.
Important callout: Stories are estimated, not individual tasks making up stories
Here’s a little secret: The team will only be right about 50% of the time. Don’t get as hung up on Story point estimating the same way you used to get hung up on estimating number of hours for tasks. Given the 50% correctness, the number of Story points per sprint tends to average out over time.
Now that your stories are groomed and pointed, you are ready for your first Sprint Planning! Can we hear a Woot! Woot!
< Back to Chapter 3 Story Writing —– Chapter 5 Sprint Planning >
Want your very own pdf copy of the handbook?
Click Buy Now and we’ll email you a copy for 50% off the Amazon cover price.