In Jira, is it possible to use story points AND hourly estimates?

[Phil Newby]

Hello

I've begun to look into story points as a method of assessing the effort a developer needs to expend in order to complete a task. This is a nice idea but ultimately it still comes down to time and when my product manager/members of the board breathe down my neck and ask for timelines, they want it in when the work will be done, not our bandwidth for new tasks.

To this end, is it possible to use both hourly estimates and story points on a project? If so, are there any potential issues to doing so?

My end goal here is to make a system on Jira where project reports can be easily generated and maintained for reporting purposes, because currently this is done by person, by board.

Thanks in advance!

[Nic Brough -Adaptavist-]

So, the simple answer is "yes and no".

Yes because you can put whatever estimates you like on your issues.

But no, because you should only use one estimate metric for everything (and if you're being a bit scrum or kanban-like, the boards have to work with a single metric - Scrum can use any numeric value, but only one of them, and Kanban doesn't have estimates directly, it measures throughput which can be used to inform wider estimates)

Story points are not analogous to time, they're a relative measure intended to enable the team to work out how much they might get done in each sprint.

If your people are demanding timelines or dates as to when things will be done, then I would be tempted to stick with time estimates and not bother with story points, as that will at least get them some tracking.  But I'd also recommend that you tell them to stop pretending to be Agile, because the only answer to "when will this be delivered" in Agile, is "when it's ready"

All that said, it's not uncommon to see Agile teams have two tracking metrics - Story points to help them estimate, plan, and report on sprints, and then they log actual time spent on issues, sometimes for just timesheeting, but often for feeding time usage data up to the management who don't really understand Agile, but have been told they are...

[Phil Newby]

You make some interesting points here, I've said before that we're working to hard deadlines but we're estimating in hours, which is leading to us making very vague guesses, overly padding estimates and making project planning very difficult.

We set hard deadlines but start to finish is essentially one big guess until we reduce that fog from the project horizon - but by the time we realise a ticket that was estimated for 4 hrs is actually 10 hrs more than once or twice across the project, its usually too late to get that time back from other tasks. So we unfairly crunch our developers or tell the client it'll be ready, but later than intended.

A few developers and designers have been overworked in the past because hard tasks are not always long tasks and vice versa. This has led to us giving 1 or 2 hour long tickets to a developer who has been quite overworked by it as a result because it involved a lot of micromanagement or stressful work on their side.

As you may have guessed already. We label ourselves as agile. But we only comply with about 20% of it.

[Nic Brough -Adaptavist-]

Yep, the "deadline = " thing is a giveaway that you're not Agile.  Agile doesn't cause "crunch the developer" or "tell the client it will be late" because they don't happen when the deadline is "when it's ready".

There is one agile principle you should be pushing though - the continuous improvement element.  You should be refining your estimation process so that you don't end up with stories that are underestimated.  You absolutely should be making "overly padded estimates" - it's always better to over-estimate a bit than under estimate and be held to something it turns out you can't do.  (Over estimating is not Agile, but doing it to inform the others around you and help them improve their processes as a result certainly is!)

No matter how hard that might make project planning, it will help prevent failures, and push your management to set more realistic deadlines, ones that you actually can meet.

[Phil Newby]

Thank you thats very helpful

How would you get around the fact that clients and board members often just want hard dates rather than 'when it's ready'?

I'm currently struggling to develop a fully agile project development method while the customer often just wants a hard, static date

[Mark Segall]

Hi @Phil Newby - This is one of the most common problems organizations face.  They say they're "agile", but still want to see waterfall reporting.  Time tracking will do your team a horrible disservice because once you put static timing on things, your product management/board will hold you to that (largely fictitious) timeline.  Instead, I recommend the following approach:

Place heavy focus on release date and MVP - Development is not a repeatable process like building tract housing. It is full of surprises. So, come to an agreement that you'll get as much done in n days as your team can handle based upon your velocity. The product manager needs to feel the pressure of ensuring they are prioritizing features effectively so that the best possible product can be delivered in the time window.  

Then, after each release, come back together to determine if the remaining work warrants additional funding to continue.

[Phil Newby]

I think your first line summed up my situation perfectly. I want to focus on how strained our production team is, but upper management and my product manager want hard numbers not velocity or to know how strained our teams are.

No matter how agile we are, the board just want 'is it done yet?' rather than 'do we have the capacity and resources to complete by X date?'

We currently aren't using releases - but I'm trying to push for a system where we do. I've said similar things about development of software not being a repeatable process also, but it's been hard to hammer that point home.

I'll add this to my planning doc - your help is much appreciated, thank you!