The TMD User Story Points Estimation Process
Estimating Development Effort
User Story Points starts with a User Story that describes some requirement that is currently missing within the Business Domain, the “Problem Domain”.
It is Referred to as the Problem Domain
… Because at this time
…… It is Missing Required Business Features
A User Story Points represents Levels of Development Effort, not Hours, Days or Weeks.
User Story Points create “Development Buckets” of relative levels of effort as defined by the Sprint Development Team during the Story Point Estimation session.
User Story Points do represents “Time” but not as a “Fixed Unit of Measure“.
The Story Point is defined as:
… The Ability to Assign an Agreed Upon Level of Effort
…… Of a Backlog Selected Sprint User Story
…. Based on the Relationship to the Other Stories
…… Using a Baseline User Story as a Reference
A “Baseline User Story” is a Backlog item that has an agreed upon Story Point of “5”.
Development Bucket Story Points, agreed upon during Sprint Planning, are created by consensus by Sprint Team based on the available skills and experience of the Development Team.
Understanding the Level of Development Effort of a User Story helps us gain a better understanding of the Level of Difficulty that a User Story Acceptance Criteria task represents to a single Developer.
A Story Point of “1” for Developer “A”
… May represent 4 Hours of Developer Time
A Story Point of “1” For Developer “B”
… May represent 8 Hours of Developer Time
A consensus of effort is reached based on past experiences of the Development Team not the time it will take to complete a single Story Point estimation.
It is during the Story Point Estimation process that each team member evaluates the Skills and Experience Required for the effort requirement of a Story Point.
It is during the Task Hours Estimation process that the story point estimation effort requirement is accepted by a Developer who Possesses the Skills and Experience Required to estimate the Story Point as Task Hours
The Agile Story Point Estimation process creates a Creative Team Environment that concentrates on the reality of Development Effort and not be influenced by the Time Constraints that always exists within a development engagement.
A Parable of Story Points and Development Task Hours
There was a Sprint Team that consists of a Child and a Brain Surgeon.
Their product backlog includes two items:
- Lick 1,000 stamps
- Perform a Simple Brain Surgery – Snip and Done
These items are chosen for the upcoming Sprint iteration.
These tasks are estimated to take the same amount of time.
Despite their vastly different complexities
… Both item items should be given the Same Number of Story Points
…… As each Task is expected to take the Same Amount of Time
In Agile estimating, we assume the right person for the job will do the work.
We do not assume the child will:
- Finish High School
- Complete Undergraduate School
- Graduate from Med School
- Do a Seven-year Residency
- And then begin the Brain Surgery
while we have a skilled surgeon sitting in a cubicle licking stamps.
The Right Person
… for the Right Job
The most popular process for estimating the effort
required for a Story Point is the game “Planning Poker”
Estimating Story Points with Planning Poker
The Fibonacci Numerical Sequence is a recurring sequence in Nature.
This sequence has proven to be the most accurate number sequence for the Nature of Software Development as well.
The first two numbers in the Fibonacci sequence are 1 and 1, or 0 and 1.
This depends on the chosen starting point of the sequence.
In Software Development we start with 0 and 1.
Each subsequent number is the Sum of the Previous Two Numbers.
The first seven numbers in the Software Development Series are:
0, 1, 2, 3, 5, 8 and 13
This represents the First Order of Magnitude of Software Development Complexity.
In User Story Points estimation history has shown that keeping the scope of complexity to single order of magnitude creates estimations that prove to be more accurate in the real world.
Planning Poker Estimation Process in Detail
The Planning poker game relies upon Team member opinions, Technology analogies, and real world experiences into a fun game approach to estimating complexity of User Story development
This process results in rapid but very reliable complexity estimations.
It is important in planning poker includes all of the Developer Team members involved in the upcoming Sprint.
This includes the Scrum Master, Product Owner, Architect Team’s Designers and any other team representatives required for the selected Sprint activities.
These Sprint Team members include the Business, QA and Network Infrastructure representatives.
Any given Sprint Team should not exceed ten members. This does not include the Product Owner and Team representatives; they can be represented across multiple Sprint Teams.
Each Sprint Team estimates independently to keep the size down.
The Product Owner and Scrum Master participate in the Planning Poker game but do not estimate task’s complexities.
The Poker Game Process
Planning Poker uses playing cards similar in size to regular poker playing cards.
Each of the estimating team members is given a deck of cards that represent the First Order of Magnitude of the Fibonacci Numerical Sequence.
The seven card deck reads: 0, 1, 2, 3, 5, 8 and 13
A Zero Level of Complexity Represents that the Estimator
… Has Knowledge that the Requirement Being Estimated
…. Has Been Developed and Available with Minimum Work
The Poker Decks are prepared ahead of the Sprint Planning meeting by the Product Owner for all meeting recipients that will be participating in the estimations.
Poker Cards are returned to the Product Owner after the estimation session is concluded.
For each selected Backlog item to be estimated, a selected Estimation Moderator reads the description.
Estimation Moderator should be the Lexicon Master as it will help to maintain the Ubiquitous Languages integrity but it can be any non-estimation team member.
The Product Owner will answer any questions that the estimators have about the Backlog item.
It is important that at some point additional discussion does not lead to improved accuracy.
An accepted technique is to have available a Two Minute Hour Glass Timer and turn it over by the Estimation Moderator for all to see when an issue is being discussed.
The discussion ends when the “Sands of Time” expires.
The goal in the Planning Poker game is not to create an estimate that is “Bullet Proof”.
The Planning Poker game goal is create consensus where a valuable estimate can be arrived at the lowest reasonable complexity number.
After all issues are answered, each estimating team member selects a card from their deck with a Story Point number that represents their complexity estimate.
Cards are not shown until each Sprint Estimation Team member estimator has made a complexity number selection.
At that time, the Estimation Moderator requests that all cards are simultaneously turned over view viewing by all of the Sprint Estimation Team members.
The Estimates May Very Well Differ Significantly
… This is Actually the Purpose of this Exercise
When estimates differ, the High and Low Estimators have a maximum of two minutes each to explain and justify their Complexity Estimates with the entire Sprint Planning Team.
It’s Important Not to Attack the Team Member’s Estimate
… You want to Understand the Motivation behind the Estimate
Remember the Team Member would not be in the Meeting
… if their Professional Opinion was not Valuable
The Estimation Moderator takes any notes that will be helpful when this User Story is being developed and tested as part of the Ubiquitous Languages Lexicon of Terms.
Notes for the development of supporting documentation can be created and given to the Architect Designers.
After the discussions are completed, each estimator re-estimates by selecting a card for display.
Story Point cards are once again kept private until everyone has estimated, at which point they are turned over again at the same time.
In many cases, the estimates will already converge by the second round.
But if they have not, continue to repeat the process.
The goal is for the estimators to converge on a single estimate that can assigned to the Business User Story’s Complexity Bucket.
It rarely takes more than three rounds, but the process should continue as long as estimates are moving closer together.
It is not required that all estimators turns over a card with exactly the same estimate written down.
If an estimation collection returns a set of 5, 5, 5, and 3
… Ask the low estimator member if they are OK with an estimate of 5
Again, the exercise is not about absolute precision but a reasonable “Estimation” in a timely fashion.
The Product Owner has the Responsibility
… For Resolving User Story Point Estimation impasse.
The next step in the Task Estimation Process is using
the Story Point Buckets as Levels of Development
Difficulty to estimate the Sprint Developer Task Hours
The Sprint Developer Task Hours Estimation process is next in the TMD Agile Series.
This process will take a major commitment by Business Management and all Agile Sprint team members for a successful outcome.
It is possible to attain a level of success without all of the details above but time has shown that if any of the process steps are diminished so will be the Business results.
This process, when designed into the Sprint iteration by reserving the last two days of the iteration as Development Overhead, Technical Debt Development and Sprint Planning Poker, will have a Return On Invested that will be easily quantifiable.
The Business Stakeholders will see the business value through improved Production releases and a better understanding of the Problem Domain by all of the engagement Team members.
Wisdom Pearl # 122 – Open Your Mind to Possibilities
There are Generally a Hundred Ways to Accomplish some Task
… But Only a Handful of Good Ways
…… Have an Open Mind to other Possibilities