How To Estimate Effort For Stories In The Scrum Framework? This Might Surprise You!
All user stories within the Scrum Product
Backlog have to be estimated to allow the
Scrum Product Owner to prioritize them and
plan releases. That means the Scrum Product
Owner needs a reliable assessment of how much
the delivery of each user story will take.
Nevertheless, it is recommended that the Scrum
Product Owner does not interfere with the
estimations that the Scrum Team performs. So
the Scrum Team delivers its estimates without
feeling any pressure from the Scrum Product
Owner.
The Scrum Framework itself does not prescribe a
way for the Scrum Teams to estimate their work.
The teams who rely on the Scrum Framework do
not deliver their estimates of user stories based
on time or person-day units. Instead, they
provide their estimates by using more
abstract metrics to compare and qualify the
effort required to deliver the user stories.
Common estimation methods include:
- Numeric sizing (1 through 10),
- T-shirt sizes (XS, S, M, L, XL, XXL, XXXL), or
- the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, etc)
An Example User story
The Scrum Team members must share a
common understanding and consensus of the
unit of estimations they use so that every
member of the team feels and acts comfortable
with it.
Planning Poker® / Scrum Poker
One commonly used method for the estimation
process is to play Planning Poker® (also
called Scrum Poker).
When using Planning Poker®, the social proof
influence among the Scrum Team members are
minimal. Therefore, the Scrum Team produces
more accurate estimation results.
What you need to play Planning Poker® game is
straightforward:
- The list of features to be estimated
- Decks of numbered cards.
A typical deck has cards showing the Fibonacci
sequence, including a zero: 0, 1, 2, 3, 5, 8, 13, 21,
34, 55, 89. Other similar progressions are also
possible. The reason for using the Fibonacci
sequence is to reflect the uncertainty in estimating
larger items. It would be a waste of time to
discuss if a user story should have a size of 19, 20
or 21. And yet, it's relatively easier to decide if
the user story fits better to the size 13 or 21.
A high estimate could mean that the Scrum Team
members have not very well understood the user
story yet. So they can attempt to secure extra
capacity for contingency before their commitment
to this user story. Alternatively, that could
also mean that the user story should be broken
down into multiple smaller user stories.
Scrum teams can usually estimate smaller and
clearer user stories with higher confidence.
Finally, the Scrum Team plays Planning Poker®
by adhering the following steps:
- The Scrum Product Owner presents the
story to be estimated. The Scrum Team asks
questions, and the Scrum Product Owner
articulates the user story in more detail. If the
Scrum Team has to assess many user stories,
estimates can be time-boxed in a way that the
Scrum Team does not spend more than a few
minutes for each user story. If the team cannot
still estimate a user story in a given time-box,
then this could be a signal to which the Scrum
Product Owner needs to pay attention. This
signal indicates that either the end-user
requirement or the user story or both of them
are not clear enough, so they need to be
rewritten.
- Each member of the Scrum Team privately
chooses the card representing the estimation.
- After everyone has selected a card, all selections
are revealed.
- People with high and low estimates are asked
to explain their assessment because they may
have thought something that the majority of
the Scrum Team members have been unable
to see.
- Another estimation is done for this particular
user story until the team reaches a consensus
for an estimate.
- The Scrum Team repeats the game until they
estimate all user stories.
Planning Poker® is a registered trademark of
Mountain Goat Software, LLC.
Share It With Your Colleagues and Friends to Help Them Learn:
How To Estimate Effort For Stories In The Scrum Framework? This Might Surprise You!
|
|
|
|
|
|
|
SCRUM INSTITUTE™
