Double counting of estimates (jira agile)

[Rahul Aich [Nagra]]

Hi

We use jira-agile and we are facing a problem with burndowns getting overinflated.

Scenario: We have a user story which is estimated at start of sprint say 10 days; the burndown displays 10 days of work. But during the course of the sprint, developers break down the user story into smaller sub-tasks and assign estimates to it. Now these sub-tasks are basically fragments of the user-story rather than additional work, however, the burndown gets inflated due to these addtional sub-task estimates.

What is the way out of this problem?

Rahul

[Chris Stemen]

Hi Aich,

The problem here is not with JIRA, rather you are continuing to breakdown and estimate work during a sprint, which you should not do.  The team should be doing regular planning and backlog grooming with their PO prior to the sprint, such that the team can agree upon the work to be done in the next sprint (yet to start).  This process does not happen during the sprint, otherwise there would be no point to sprint planning.  Once the sprint has started, your team should do everything it can to maintain the sprint plan and complete the work in priority order.  If estimates for all work agreed upon by the team were not planned prior to the sprint, then your team has essentially agreed to nothing, right?  Your next question might be "how can we know what the estimates for work will be without starting work and evaluating what needs to be done"...the typical old-school waterfall project planning itch we all want to scratch.  Don't do it!

It is completely understandable that you will have work which is hard to estimate precisely.  Agile best practices are meant to alleviate these concerns.  Use agile concepts, rather than game the tool, to improve your team output:

1.) Estimate your backlog in story points (or any non-time based relative sizing mechanism based on complexity).  There is no correlation between story points and time estimates.  You should try to estimate as much of your backlog as possible, and not just one sprint ahead because what if things change?  You need a groomed backlog so you can bring issues into the sprint when priorities change or the team produces faster than expected.

2.) Sprint in reasonably short time-boxes.  Two week sprints might be standard, but it really is dependent on what your team can handle.  The longer you sprint and the more specialized your team is, the more waterfall you naturally become, but you can only determine the best sprint length by identifying what it takes to deliver potentially shippable product (a farmer can't sprint faster than it takes for the corn to grow kind of thing).  This sort of determines your agility.

3.) Put the riskiest work (i.e. requirements who's architectural solutions are hardest to know or solve) as early in the release as possible.  This process brings to light the most important issues that need to be discovered for proper design before much work is done that could be impacted by a uncovering design or requirements problems, and therefore would need to be reverted.

4.) Use time-boxed Research Spikes to work through the heavy unknown parts of a feature.  Most of our releases start with a lot of research spikes towards the top of the team's backlogs.  These are generally 1 day in length, and a check-in is held to determine if work can be started or a solutions design is achievable.  If more time is needed, so be it - do another research spike.  The point is, they just shouldn't go on indefinitely.  A decision needs to be made.

5.) Story points help to prioritize the backlog and plan your release, but you can use hours to estimate your sprint!  The purpose of the story point is really to help get developers to stop worrying so much about time commitments, but when it comes to something like a two-week sprint, it is reasonable to ask someone how long something might take.  Nonetheless, try not to tie your time estimates to the story point value!  This defeats the purpose of story pointing.

6.) Average work days should probably not be assumed to be 8 hours (or whatever your punch-in/punch-out routine is).  We estimate the average product work day for a developer to be 4 hours.  The remaining 4 are consumed with meetings, doctor's appointments, shoulder-tap interruptions, long lunches, etc.  This is fairly industry standard.

7.) Consider using sprint buffers.  A sprint buffer is a block of hours removed from the sprint capacity calculation that is only used for unplanned events.  Maybe your team gets impacted by customer issues from time to time, or you have defect debt you want to work on, or regular maintenance issues.  You can cover this in a sprint buffer and track how much you tend to consume, so it can be adjusted over time as your team gets some data on how often it gets interrupted.  In a perfect agile world, this concept would be unnecessary, but until  your team is really good at scrum, it can be beneficial.  We don't have our teams use the "Log Time" function in JIRA at the moment, but we do use the log time on a sprint buffer issue in the sprint, where they track work hours on unforeseen interruptions.  I then go back and track how many hours each sprint are logged to the buffer and use that to plan buffer time in the next sprint.  It tends to fluctuate depending on what is going on with other teams, other releases, resource issues, etc.

7.) Only use the burndown to track how the sprint is going from the perspective of the overall sprint objective.  If your team is over the line, that is ok, but if this continues consider meeting with your PO and reviewing what from the sprint could be dropped (assume the lowest priority issues), and verify with the team that this change in sprint scope is ok.

8.) All stories do not need to be written to start working on a release!  In fact, story writing is a continual process, where POs are regularly adjusting their requirements based on how the solution starts coming together, how representatives from your customer base respond to the work demonstrated from sprint to sprint, how market conditions evolve, etc.  If all stories are written up front, then you might as well be back in waterfall mode.  This does not mean there can't be a release plan and scope!  But the more you try to plan out ahead, the harder it is to stay agile.  Customer collaboration over contract negotiation!

9.) Lastly, try not to operate in a Fixed Scope and Fixed Date release mode, rather do one or the other if at all possible.  Unfortunately, this is how most projects are, but in the software world, especially as agile continues to be adopted, we should be training our POs and clients to be more comfortable with one or the other, and being more tightly involved in the potentially shippable product each sprint, rather than waiting until some date where everything would be due and everything in their world has changed.

Note: If your team has a lot of new members or experiences high turnover currently (new company, re-organization, etc.), you must plan in knowledge transfers and cross-training, and do it ASAP.  This will payoff in the long run as the team will be more predictable and produce more consistently.  It also puts a focus on removing specialization, which cranks the agile knob down because you get bottlenecks centered around skill sets and product knowledge.

I expect you were looking for a simple solution to how the hours calculations work in JIRA, but in my humble opinion, this is more about agile practices and not a problem with the reporting tools.

-Chris

[Daniel Wester]

The system is doing what you've asked it to do...  You'll need to decide where you want the estimation to occur and remove the story point from either the subtask issue types or the main issue types.

If you want to still have the estimation of the subtasks - create a new field for it. Or maybe do the estimation in hours there and use the time logged feature.