Story point estimtaes Vs Tasks hour estimate

What method of estimation do the Development Team think they ought to use, which would allow them to forecast their Sprint Backlog most effectively?

Generally speaking, if stories and tasks are used, tasks can be sized in hours because they are sufficiently fine-grained to support reasonably accurate time-based estimation.

However, instead of trying to prescribe a certain technique, it would be a much better use of Scrum if the team inspected and adapted their own process. A Scrum Master should encourage them to do so.

Hi Rasha, 

I had such case about 2 years ago when the SM of one of the team (at that time I was a member of Dev Team) decided to implement Fibonacci numbers instead of hours. Maybe, in general, it is a good idea but for us, it was much more convenient to estimate in real hours instead of Fibonacci numbers. So, after 2 Sprints we decided to return to hours. In my mind, there should such method for estimating which is more preferable for the Dev Team.

P.S.  By the way - now we use Fibonacci numbers

Pure coincidence I had this question yesterday and spent some minutes with the team explaining my humble opinion on the topic.

First:  I've been with this team for just 3x 2-week sprints; they are 8 months old and were up to Sprint 21 from memory.

They had never been taught Capacity Driven Sprint Planning;  on their first Sprint Planning with me they were visibly stunned.  I was taken aback at their surprised reactions.  "That is the first time we've finished Sprint Planning with no stress and arguments!"  "Huh?" - I was really surprised.  "We never finish on time and we always argue!  And this is the first time we've both finished on time, it was a relaxed meeting and we finished on time."

Although I wasn't around before April with this team, I believe they were being forced into a push-type velocity driven sprint planning technique;  management had probably gotten hold of velocity and perhaps they were being asked questions like "How much velocity do you have left?"

Capacity Driven Sprint Planning is a technique to ensure that no single team member bites off more than they can chew and therefore crashes the sprint.  I accept that "crashes" the sprint is a harsh term - it's all about learning, right?  There is no such thing as a failed sprint, only learning opportunities.

Capacity Driven Sprint Planning goes something like this:

• Approx 10% of a Sprint's time is in the events
• Upto 10% of a Sprint's time is future-looking, Lean's Just-In-Time Analysis, Backlog Refinement
• That leave's approx 80% of the 80-hours in a typical 2-week Sprint to work on the pulled-in-by-the-team / selected Product Backlog Items.  Call it 60 hours for round numbers.  Work expands as you get into the detail anyway
• Once the Topic 1 of Clarification and Conditions of Satisfaction / Acceptance Criteria are out of the way and the team understand what the customer wants and under what conditions they'd be satisfied it is done, the team can then start the conversation of "Tasking out" - not 100% of the tasks because we know that work expands as we get into the detail - but just enough to kick off a conversation, discuss, collaborate (agile manifesto value statements #1 and #3) and be able to forecast whether they believe they could deliver this item.
• As each team member identifies tasks and volunteers for that task - a Product Backlog Item is given to a team, never an individual;  Tasks are what Individual Team Members work on so that collectively Team Members deliver the Product Backlog Item as a team to the satisfaction of the Product Owner - they chip away at their hours.  E.g. if they take on a task that is roughly 8 hours then they use pen and pad to reduce their original 60 hours to 60-8=52.
• And this cycle of repeatedly chipping away at their running total of hours remaining continues.
• It's purpose is to assist Team Members from ensuring they don't take on a pressured, stressful workload.
• You can tweak this technique to assume 6 hours in a typical contract's 8-hour day (or 7, depending on your flavour).

Once the Task Time in Hours has been used;  throw it away.  It's served it's purpose.

It has nothing to do with Story Points (relative size of effort weighted for complexity, uncertainty and risk) or Ideal Days (an attempt to say "If circumstances are ideal e.g. all Risks, Assumptions, Issues and Dependencies are mitigated or do not exist, so an Ideal situation, how long in days would this team take to do this item to the satisfaction of the customer?").   Individual Team Members' Task Time in Hours is used to assist in Planning to ensure workloads are not compromised and factors in Public Holidays, Personal Holidays, any Corporate Overhead such as Mandatory HR Training; Ideal Days is one long-term-planning / collaborative conversation provoking Estimation Technique.

If that's helpful?

I've had huge success with this over the years.

Hi Rasha,

I've always found estimating the stories in points and tasks in hours. SM probably wants to use story points because he/she wants to see and monitor the velocity of the team. If you use only hours, this won't be possible as the total capacity of the team will always seem to be constant which would be equal to number of hours in your sprint length. 

Hi everyone,

Let me share our way of doing Sprint Planning.

So basically after the team knows the "wish"of our PO in regards to sprint scope,  they go into planning 2 where they breakdown the UserStories into subtasks and they estimate each subtask in time using hours.

In the beginning of planning 2 we start calculating the capacity of the team for the sprint due to holidays, trainings, meetings, or maybe new joiners, and then we see how many hours do we actually have for sprint scope work. Of course we remove from the capacity the time spent in scrum events. 

 After capacity forecast we get a rough idea how much time we have in the upcoming sprint for actual work.

After that when the teams are finishing the time estimation we make a check vs the capacity and what fits into the sprint  becomes the forecast and what does not fit into the sprint will fall into the product backlog.

Of course the teams also use their gut feeling  when forcasting taking into account team velocity and their feeling and not only capacity check vs subtasks estimates

beside that we estimate user stories in story points

so far it worked quite good :)

now we want to try to see how it feels to just use the team's velocity without estimating the subtasks in time

hope this helps bringing some clarity

cheers!

now we want to try to see how it feels to just use the team's velocity without estimating the subtasks in time

We are doing just as you have mentioned above. We know our velocity is 15 story points(When all developers are present for all 10 days of sprint) . We estimate stories like below-:

1 story point= Simple

2 story points= Medium complexity

3 story points= High complexity

5 story points= Complex but can be completed in 1 sprint

8 story points= So complex or big that it needs to be divided and cannot be taken in a sprint

How we decide if story is of medium or high complexity ? It's a collective decision of development team. So, basically if you want to climb a rope of 3 meter and you ask complexity of this task to 10 people after giving above chart (1=simiple, 2=medium), I am sure out of 10 , 60% will say 1  and remaining will say medium. Noone will say High. Similarly, while estimating story, majority of developers will give good (Close to reality) estimation.

This way we select 15 story points.  One thing I would like to add is we calculate capacity in terms of Percentage and not in terms of hours. So, if our capacity is 80% only, we select 80% of 15 story points= 12 story points only.

It is important for the team to know and realize:

• The story points and the task split up that is being owned up by the team that sprint.
• The bugs for which time estimates cannot be realistically made. a 1.5 day investigation time box is devoted.
• The actual time available on the sprint (business days - holidays - vacation days)
• Every sub-task is truly not more than 1.5 days.

Given these 3 parameters, and the assumption that a scrum team is sized according to scrum efficiencies, it is enough to ask the team to commit to the work. Committing to the work as team automatically implies committing to all work items within the time box of the sprint without necessarily making time-wise break downs. 

The moment one puts time to any work break down items

• There is a notion of how this time will pan out between one developer and another. Work will always flow in the direction of the person who estimates the least time.
• SM and upper management can use time-tracking in ways which could hurt team members' morale. A team is rarely a composition of tigers. Some are good in certain areas and some are not. The team must be facilitated to improve as a whole not as individually in niche areas.
• A bigger question of why use story points comes up. Story points are an estimate of the effort, complexity and uncertainty of the work and need not correlate very well with time estimates.

It is enough to track the the story point burn rate and the bug burn rate per sprint rather than really track fine grained time.

my 2c.