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.

1. The TA will introduce you to a user story.
2. 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.
3. Look around your team, and see how close you are towards consensus.
4. If someone is an outlier, they usually speak out why they voted so differently.
5. Others chime in with explanations, ideas for potential solutions, as well as information sharing about how that section of code may have been developed.
6. 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.
7. 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.