How do you get a sprint burndown to show estimated time when you have multiple developers ?

[Ian Barron]

when we set up our burndown charts in Jira the estimated completion time is shown as the cumulative remaining time of all of the issues in the sprint irrespective of how many resources are in the sprint.  For example if developer 1 is assigned to work on component 1 and estimated 2 days and dev 2 is assigned to component 2 and estimated 3 days then the estimated completion of the sprint will be 5 days rather than 3 days.   Are we doing something incorrectly or does Jira just not handle resources like expected ?

[Ian Barron]

hi Scott,

so i should set the 'Tracking Time settings'  to something like the following image for 2 full time, fully productive people ?

[Scott Theus]

Yes, I believe that would work.  (I'd try it on a test project first though :) )

[Ian Barron]

I gave it a try before sending the mail to you ;-)  it appears to work - but you have to set both hours and week definitions :-)

-Ian

[Scott Theus]

Hi Ian,

The burndown is a measure of the work completed over a set time period, not time elapsed. It uses a set number of days for the sprint, the total work to be completed in the sprint, and shows how much of that work is done and, if there is a trend line, whether the work will be completed within the sprint. If the sprint is showing you 5 days of work it is because your developers estimated that amount of work for their tasks, It does not take into account the fact that you have two developers working at the same time, so the work effort will be completed in a shorter amount of time.

This is why Story Points are often used instead of time; they represent the amount of work effort needed regardless of the time it takes to do it. 

Does this help?

-Scott

[Ian Barron]

Hi Scott,

Thanks for the reply.  unfortunately it was the answer i was afraid i would get … 

We had been hoping  to be able to use Jira to help us plan sprint completion dates and plan what can be accomplished (ie. how much can be realistically done in the sprints ) by preset release dates.  or what resources do we need to assign to get x done by a preset release data. Or what is our prognosed release data given the current progress.

Obviously we can't do this if it sees everything as a serial, single resource, time stream.

The other reason for tracking time rather than an artifact like story points is that we can have an idea of what the software actually cost to produce.  

-Ian

[Scott Theus]

Yeah, that's a drawback with sprints that I've run into a few times, especially when the PMO is only "Agile-ish" and management wants to see Waterfall reporting from an Agile project. 

Try using a set time box for all of your sprints so they are all the same and estimating how much work your team can do within that time. You can use "man hours" for this instead of story points, as long as everyone understands that the man hour represents work effort, not time. 

For example, let's say you have a project with 1000 hours of development time and two developers, and your sprints are two weeks long. Developer 1 is seasoned, so in a typical 40 hour work week he feels he can complete 30 man-hours of work. Developer 2 is newer and may need more time, so in the same 40 hour work week he can only do 15 man-hours. That gives you 45 man-hours available per week, or 90 man hours per sprint. Divide the 1000 hours estimated for the project by the 90 man hours and you get approximately 10 sprints, each one lasting two weeks, so your project should that 20 weeks. 

The burndown will show you how well your team is doing against their estimates, and the velocity will show you if they can take on more tasks in a sprint or if they need to reduce the number of man-hours. 

Using man-hours will allow you to estimate cost, and when you compare that against actual you can use the variance to improve your estimates. 

-Scott

[Scott Theus]

BTW...you can also use an add-on like Big Picture to manage your resource allocation and capacity. 

-Scott

[Ian Barron]

thanks Scott,

i think what you suggest is very close to what we are doing - ill need to read your reply a few more times and digest it better :-)

-Ian