Estimations in Agile project- Part 1 (story points)
Introduction to estimations?
Which estimation technique(s) is better used at?
What’s Velocity?
User Story write up?
Summary and notable points?
Introduction to estimation:
As per BABOK guide, ‘Estimation(s)’:
Is used by business analysts and stakeholders to forecast the COST & EFFORT for business analysis activities.
For time and effort needed for elicitation and associated cost.
For prioritization.
Is used to determine the size of the change.
Is used to determine timelines for activities within the change strategy.
Is used to forecast the costs and efforts of meeting the requirements as a step towards estimating their value.
Is an Iterative process.
Estimations are at times single digit numbers representing the “confidence interval”! Confidence interval…!! Yes, you read correctly, let me tell you:
Estimations are represented with minimum and maximum value range measuring the uncertainty levels. So, lesser the information for an estimator, the wider the confidence interval. Hence, estimations are reviewed and revised as more and more information is made available.
All projects aka software projects, should consider reliable estimates and not CORRECT estimations. If a Scrum team can forecast what amount of work can be done in shorter time-box, then we can reliably say what amount of work can be completed in next 2 weeks or 2 months. With effective estimation, the scrum team knows where they are now and what’s next in store. Which means, as per the completed 2 weeks or 2 months of estimated work, they exactly knew how to plan and estimate for the upcoming work.
Doesn’t it sound fair and promising?
Doesn’t it give an assurance and confidence for scrum team and project management to plan their next project?
Yes, this is where the Agile philosophy is appreciated. Effective Agile estimation helps companies, business analysts, stakeholders and scrum teams to predict how much amount of work can be accomplished with existing team’s velocity. And the outcome will be a well-planned iteration with minimal risk.
Dean Leffingwell perfectly says, “estimating is the key to unlocking the ability to commit”. Some methodologies or frameworks might not give importance or needed attention to estimations. From Lean perspective, some might even see estimations as a form of waste. But what’s the central value that estimations add to a project and organization are:
Commitment
Work schedule
Cost: If efforts are not estimated, then no effective cost is estimated. Output= no business estimation.
Cost of Delay (CoD): Developmental efforts not estimated leads to delayed delivery.
Prioritization
Which estimation technique(s) is better used at?
There are two basic techniques-
1) Estimating story points (estimates in size)
2) Estimating ideal time (estimates of duration).
In this part 1, we will read about the Estimation in story points: In software projects, we need to know if the user story is large or small compared to other stories. There is no defined formula set for sizing, instead it is a combination of scrum team efforts, complexity of user story, risk involved etc.
So relatively, a story point estimation considers:
How much did we understand?
How complex is the story?
How much time and efforts are needed to implement?
What are the possible risks and objects that might affect?
During relative estimation, a preliminary design discussion is fine, but much of time shouldn’t be wasted.
Steps: -
Time boxing: 1 hour/ 2-week iteration.
The Fibonacci series-0,1,3,5,8,13,20,40,100 helps to show up bigger stories that poses uncertainty.
A scrum team either takes a small user story and assign 1 point or a fairly bigger user story and start with a 5 pointer. Referencing this story point, the Scrum team continues with rest of the stories.
In an Agile project, the team starts with a hypothetical story point estimation when met with incomplete requirements.
Estimates are made by the entire team which comprises- product owner with the list of backlogs, business analyst, developers and testers to quickly discover the size.
The relative estimates are made with either one of the two most popular techniques-Planning poker and Table Top. We shall read more about these in next article (part2).
While the above 5 points focus on estimating sizes, they don’t throw light on the how long scrum team(s) takes to finish the delivery. To fill this gap, we move towards the team velocity.
Velocity:
Is the measure of team’s rate of progress in the given iteration. It is the sum of user story points given to each story accomplished by team in an iteration. In short, a team’s velocity is how many points they can complete in the given iteration.
If Scrum team completes 2 stories each estimated at 8 points, the team velocity is 16.
If 3 stories each of three-story points are completed, then velocity is nine. So, the total project size estimate is sum of all user story points.
Given the team’s previous working knowledge, they can guess how long (iterations) they will take to come up with definition of done. This prepares the team to plan their next iteration estimates.
Velocity helps scrum team to correct their estimation errors.
Michael Kohn aptly puts a point- “The beauty of estimating in story points completely separates the estimation of effort from the estimation of duration.
User Story writing up:
Providing a quick write up on the user story composition, as asked by one of the article readers.
User story is the soul in Scrum development and writing it vividly solves most of the developmental queries.
A user story is "an activity an actor should be able to perform".
Acceptance criteria is "how the user story is verified".
User story should cover the following:
As an actor(s)= Who are the group of individually that work is being done for.
I want= What work is being done (accomplished to meet the needs). This I want covers function.
So that= Why the work is being done (to address customer needs). This So that covers business reason.
Summary & important points to ponder:
Story points are relative measure of the size of a user story.
Velocity is not the tool for managing scrum teams or project management activities.
Scrum teams uses velocity to measure themselves.
It is certain that, management emphasize on increasing team’s velocity parallel to the improved quality- this doesn’t mean that increasing velocity ensures productivity. Constant emphasis on teams might lead to one or all the below:
Simply increase the size of estimates.
Dip the quality effecting the product functionality.
Improves agile implementation culture, improved technical standards-coding, testing, deployment speed and continuous retrospection and team's efficiency.
#Agile #estimations #scrumteams #abcsofagilescrumframework #authorsblog #BABOKguide #agileprojectmanagement #gsubashcosmopolitan #businessanalysislifecycleandITbusinessanalystrole #amazonebook