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

Question

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!

Phil Newby · Answer

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

Nic Brough -Adaptavist- · Answer

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 · Answer

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.