A problem, however, is introduced when some team members try to correlate relative sizes with absolute amounts, such as “S = one day”, while others may use a different scale. Workdays are a subjective unit of measure and depending on other commitments, ideal days will vary. Using a simple mechanical method avoids this problem.
Only the Scrum team participates in the sizing process. Team members arrive at a sizing session with an idea of the stories and with any information that might inform their estimates.
The sizing process is similar to the one described above for prioritizing stories, except the Scrum Master leads the session. After an arbitrary story card is placed on the wall, the Scrum Master pulls the next card, reads it aloud, and asks if people think this story is larger, smaller, or about the same size as the one the wall. The vertical axis represents the size of the stories with higher on the wall indicating more effort; lower on the wall is less effort. People in the meeting say “higher” or “lower” and the Scrum Master follows their suggestions. If the team cannot agree on the size, then it is open for a five-minute discussion, and the Scrum Master decides the final position.
After all the stories have been placed on the wall relative to each other, divide the wall into five equal vertical sections. Mark the sections XL, L, M, S and XS, respectively. Drawing the five sections is a physical method for categorizing the stories by size.
Sizing the stories this way creates a visual map of the project in terms of effort. Reviewing it may highlight red flags hidden in the project. The Scrum Master should watch for L and XL stories that have lower priorities; in the last third of the project, for example. Large and XL stories toward the end of a project represent riskier work. Software projects have enough uncertainty that teams will want to avoid planning large stories at the end of a project. The PO may want to think about raising their priority, dropping them from the project, or trying to break them into smaller features.
Since the stories sizes are relative, the majority of the stories should fall into the small, medium and large categories. If there is a larger ratio of XL stories then the team should re-examine the stories that fall between L and XL. Perhaps the team has overlooked some details of the stories, or perhaps they are epics that should be split into multiple, smaller stories.
Note: relative sizing only works for stories considered during the same session, but the simplicity of the process makes it especially accessible for teams and team members who are new to Scrum.
<< Previous Tip
Next Tip >>
No comments:
Post a Comment