Lab 4—Agile sizing
Objectives
- Participate in sizing of user stories using Agile’s poker cards
- Size stories based on complexity, difficulty, and risk using Agile sizing cards
- Discuss with group when there is disagreement on size
- Identify when user stories need to be broken down into smaller stories
Exercise
Estimating how long it will take to implement features or user stories has always been a difficult task for software development. Most projects end up way over schedule as a result.
One methodology in Agile is to size user stories based on your knowledge and understanding of: Effort + Risk + Complexity.
This is a good skill to learn even in non-Agile shops because everyone involved in software development needs to develop better skills at estimating how long it will take to implement stories and to do a better job on RFPs (Request For Proposals) and contract negotiations.
Everyone is always asking, “How long will that take?”
Step 1 - Agile poker cards
Each person gets a set of Agile sizing cards. The set of numbers are:
1, 2, 3, 5, 8, 13, 20, and ?
Note that the numbers do not represent hours it will take. Instead, it is a relative number of what it will take to complete a user story. For example, frequently during a sizing meeting someone will call out: “We can’t give user story X a 3 when we said that user story Y was a 5 and user story Y is clearly much easier than user story X.”
At this point either user story Y gets re-sized, or user story X is sized appropriately with respect to user story Y and others previously sized. And from there, each group will develop over time what each number means for their team. Product Owners don’t participate in sizing, they just watch.
Step 2 - TA is Scrum Master, whole class is one team
We’ll start with the TA acting as Scrum Master and the whole class is one big team. We’ll do this for a few rounds to get you acquainted with the idea of sizing stories.
- The TA will introduce you to a user story.
- The team votes based on initial understanding and ideas about the user story.
- “Ok everyone, decide on a number. Everyone ready?”
- “Vote!” and hold up your cards all at the same time.
- Look around your team, and see how close you are towards consensus.
- If someone is an outlier, they usually speak out why they voted so differently.
- Others chime in with explanations, ideas for potential solutions, as well as information sharing about how that section of code may have been developed.
- Go to step 2 until consensus is reached.
- What is consensus? “I can live with and support that.”
- What if you cannot reach consensus?
- Add it to the research queue for the sprint to have someone research the story in more depth to get a better feel for what it will take to complete the user story.
- Go to step 1 for a new story.
Step 3 - Smaller groups
Form groups of 7-9 people (minimum of 7 required). Be sure you are all sitting together, preferably in a circle.
Repeat the steps for several more user stories that the TA presents. Have someone act as Scrum Master and record the size for the user stories presented.
Scrum Master
- Read the user story to the group
- Ask, “Does anyone have any questions about this user story?”
- If there is a question, attempt to clarify (other team members can also help answer).
- “Ok, is everyone ready to vote? Pick your card and keep it face down.” Wait until everyone is ready with a card.
- “Ready? Show your cards.”
- Look around the group, are there any outliers? If so, ask them why they voted the way they did.
- Facilitate the discussion. This does not mean you answer every question. The whole team is involved in the discussion. Facilitate = guide.
- “Ready to re-vote?” and repeat until concensus.
Credit
To get credit for this lab exercise, show the TA and sign the lab’s completion log.
Lab material by Liz Boese.