We’ve been using JIRA for 2 years now to manage sprints and developments. I plan the sprints and work with the development team using Agile methods.

I currently use rudementry reporting to track perfomance, but it’s clear this isn’t enough. I need to now do some proper reporting due to slippage and other issues.

I’m looking for a way of being able to track the total time estimates that a developer has assigned for the tasks in the sprint, against the total burnt time against the sprint.

Does anyone know of any reports on JIRA that cover this?
Alternativley, are they any plugins I might be able to use?

Another option (and this is what we’ve adopted) is to abandon the concept of estimating as it’s 99% of the time widely inaccurate and therefore a totally useless exercise.

If a ticket needs to be done, it needs to be done. if it rolls over into the next sprint, it rolls over into the next sprint. You either spend time estimating, or you spend that time trying to finish the ticket.

Might not work for everyone, I imagine.

The estimates are just that, estimates. Some tickets you finish well in time, others you don’t. It’s a bug/development tracking system not a micro-management tool. If the estimates are consistently too short then the work involved in the ticket is too much and you should split the task into sub-tasks.

@ Plython I’d like to be able to do that. I’m in complet agreemant with your reasons too.

Our issue is that the developers are outsourced and we pay them a retainer plus additional development charges. Given recent perfomance, we need to keep an eye on this. I’d like to be able to make informed quantitative decisions. I’m being asked some big questions by senior management.

@Whitestone even if that where the case(which it’s not), it would still be useful to report on estimates vs. real burn time. When I’m building the next sprint and they are underestimating by 70% conistently, then this creates a whole host of issues for the business.

Edit: Wouldn’t like to give too much detail on a public forum.

Any idea of a report or plugin available to do this?

OK, a slightly different scenario.

Who does the estimates? Are the developers experts in the particular field? Handing a job to someone who isn’t sure on the technical and legal side of the work means there’s learning time as well. The developers should also indicate that they don’t think it’s enough time if the domain is new to them. Is code review (and rework) and QA part of the same ticket?

As a start I’d ask for time on each ticket to be logged daily and for a short description of work done that day and an estimation of how far they are through the task and anything blocking progress.

Ah the joys of estimates and the bigwigs not understanding what an estimate is.

Although not familiar with Jira, were just starting go use it and used Microsoft team foundation server in the past. You shouldn’t be questioning why are they not hitting the estimates, you should be looking at why are the estimates always (if they are) way out.

Is the team learning? Learning how to point tasks up, learning from past sprints that what they thought was a small task was actually a big one?

Or is this all a totally new concept to everyone, which is usually the primary reason why point estimates are way out.

Edit: Too much detail.

I’m just looking for a plugin or report that’s able to do the OT.

Please do let me know if you know of anyhting suitable.

Why are you estimating time? Why not estimate complexity using arbitrary story points because that will give you an overall velocity for the team without the additional overhead of time measurement. The size of the points doesn’t matter, just the rate of change.

The more time you spend estimating, the less time is available for doing.

Are your estimates getting worse over time? Are things taking longer to do simply because the way the application has been built doesn’t lend itself to continual feature delivery? How much technical debt are you carrying? Do you run the risk of building a monolithic application that will eventually collapse under the weight, and this is being borne out by the decreasing speed of delivery?

How comfortable are you with the quality of the requirements? Have the development team been involved in shaping them up or are they simply told to deliver?

What is your role in this? “I plan the sprint” would imply a PM, versus a mature Scrum team who would collectively commit to deliver x amount of value within a sprint.

In my role (BA), I’ve seen different vendors provide developers of varying levels of independence and assertiveness. Our onshore ones are all very vocal in challenging things that aren’t right or requirements not good enough, whereas our offshore ones would nod their heads and say it was doable – even if not – eager to please upfront but disappoint later…

Edit: If you estimate in points then Jira will handle it easily through burndown etc, and there’s another in-built chart of commitment versus delivery. I’m not in the office today so can’t check which one

Thanks for all the points AlasdairMc.

I’m an IT bod and worked my way up. I’d love to answer those questions, amongst others, but this really isn’t a suitable place to be doing it.

All I’m looking for help on is how to report on Time Estimates vs Time Burnt in sprints.

To try to answer the OP’s original question. One of my colleagues uses a plug-in called Tempo to achieve some of what you want to do, and uses it for the same sorts of reasons you need something.

Fortunately I’m in a team where we can work purely using the ‘how many points do we think we can do in this sprint’ approach 🙂

I have absolutely no idea what any of this thread is about.

Thanks grizedaleforest, that plugin looks useful! Will dig a little deeper.

That is very fortunate. I’d love to work in an environmet with process like that. Woes of working for an SME/ startup..

Just looking at our Jira. We have Tempo and AIO for reporting. Can’t get to the “more interesting” bits of Tempo because I’m not high enough up the food chain. There’s one or two sections of AIO that I use but again they aren’t at management level.

Edit: One of the Agile objectives if you were is that at the end of each sprint there’s a deliverable: feature X will be complete and usable; bug Y will be fixed and that there’s a demo to the customer to that effect. Everything works back from that so if they say X will be done then that’s their job. Doesn’t help you with your historical problem I know but it’s how I’d be doing things going forward.

One of the Agile objectives if you were is that at the end of each sprint there’s a deliverable: feature X will be complete and usable; bug Y will be fixed and that there’s a demo to the customer to that effect.

We use similar. Irrespective of number of Jira tickets completed, we also aim for a common goal for the sprint to keep us focused. We’re playing a lot with the mindset and motivation, in addition to the ability to simply deliver code.

Thanks Whitestone- will take a look at those.

Yes, agree that it would make sense in most business cases. I think our process might be fairly unique. I’m working on an IT transformation project for the business, though I’m not sure how much I can influence it in all honesty. The ‘want’ needs to come from the top down..

I have absolutely no idea what any of this thread is about.

As someone who does, all I can say is keep it that way for your own sanity.

As someone who does, all I can say is keep it that way for your own sanity.

Fair enough.

It just struck me how the whole thread was in impenetrable jargon.

Marketplace

I don’t use it directly, but remeber the marketplace being helpful in the past, something like Charts and reports there would help I’m sure. Outsourced dev is challenging with agile approaches and delivery as I’m sure you are aware, good luck!

Is using JIRA for 2 years + using time based estimating + reporting ringing massive alarm bells for anyone else?

Your developers should be estimating using story points. You should have a history of how many story points they’ve completed in each sprint, the average of that is your velocity, which will tell you how much you can fit in your next sprint.

For our outsourced development we get the developers velocity in advance of awarding them the work and use KPIs against that – e.g. between 70% and 90% of your typical velocity = amber. less than that, red etc