Agile [Story Point Estimation]

What Is It After All?

Like any other estimation techniques, story points estimates are also about time i.e. the time efforts involved in doing something(a story). Everyone likes certainty and predictability and hence want to know when something will be done\delivered. When estimating, we need to consider all the factors which directly or indirectly influence the efforts involved.
Complexity is the base factor although other factors like riskuncertainty etc. also adds to time efforts. Each of these factors can affect in one or more phases of delivering a story. For example:
  • A story may be simple to implement however complex to test or vice-versa
  • Uncertainty for example comes in during integration testing where your team's work gets integrated into say other teams work. Both teams are confident about their deliveries, however, that anxiousness creeps in, will it work flawlessly? Will we have some rework to do?
  • Example of risk could a change required in a legacy component, where team has limited knowledge and\or the editor tools etc. are not supported any more. So one has to work with extra caution.  

Pre-requisites
  • Team members have experience of at least one successful release using Agile-Scrum
  • Team members understands the scale chosen for estimation and reasoning behind that
  • Backlogs are well groomed and acceptance criteria is present
  • Product owner is present to answer run time queries team comes up with. This becomes optional for PO who does a meticulous job while writing stories and providing acceptance criteria  
  • Definition of Done(DOD) document is in place 

Estimation Scale

There are variety of scales you can choose from. One of the standard practice is to use Fibonacci series. The reasoning behind using it is that, like the figures in the series, there can be backlogs\user stories which has compounding complexities when compared to some other ones. And thus it become easier to estimate. It is like saying, I think Story C (3) will need efforts equivalent to Story A (1) and Story B(2) combined.  At the end of day any series simply represent complexity value. So you can choose the series based on what granularity suits the team better. Just make sure that in an organization, team uses similar scales. This helps in future when we compare different metrics across teams. 

[1]    [1]    [5]      --> Very simple
[2]    [2]    [10]    --> Simple
[3]    [3]    [25]    --> Medium
[4]    [5]    [50]    --> Complex
[5]    [8]    [100]  --> Very complex 
--      --      --
--      --      --
--      --      --

Steps

Key for story point estimation is to remember that you are asked to estimate delivering a story and not delivering individual tasks like coding, unit testing, integration testing, deployment etc. Imagining it as one member (i.e. you) team helps in this exercise
  • Scrum-Master\Team lead projects the story on screen and reads out the entire details, including acceptance criteria 
  • Doubts are clarified and queries are answered
  • Team goes round robin in choosing the figure from above list
  • Prefer to go from junior most to senior most team member
  • If there are outliers, respective members will explain their reasoning behind coming up with that figure 
  • Repeat round robin figure collection until team reaches consensus
  • In case of dead-lock, which is rare, we go with majority
  • In case consensus is that user story is very complex, split it into two and then try estimating 

Do's
  • Ensure every member is participating
  • Identify one base\reference story for each complexity figure
  • --
  • --

Don'ts
  • Don't provide figure unless and until you are crystal clear on acceptance criteria
  • Don't arrive at figure by a bottom up approach by estimating each individual task in hours 
  • Scrum-Master and Product owner should not provide estimate figures
  • --
  • --

The list for do's and don'ts will keep getting better  with team getting mature from learning of the releases after releases.

Thanks!

Comments

  1. Planning poker should be used for estimation, instead of estimating in round Robin fassion.
    People get influenced because of other's.

    ReplyDelete
  2. Scrum master who will be working on sprint backlog has right to participate in estimation.

    Why should he work on the backlogs to which he has not participated in the estimation.

    ReplyDelete
    Replies
    1. I think you are referring to a situation where Scrum master is playing dual roles and is also an active scrum team member. In this case he can participate in estimation as a 'Team Member'. Hence the guideline still holds true that a Scrum Master should not provide estimates.

      Delete

Post a Comment

Popular posts from this blog

Who Moved My HR?

Passwords Passwords