Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,463,448
Community Members
 
Community Events
176
Community Groups

How to change story points to hours in JIRA

I have a scenario in my team, where members have a small activity Example: Documentation. adhoc-support, on-call support. These activities might not take more than 30 mins to 2 hours. I have configured SP as the measurement and follow Fibonacci series mechanism of 1SP = 4 hrs. 

Now to track all the activities and also adhere to the SP, I asked team to create TASKS instead of story and create sub tasks and provide SP to the parent task. Now, the trick of what if a particular sub task is in complete, we need to carry the entire TASK To the next sprint (I think so) but for my management they are worried about the reports. 

So I am thinking of option whether we can change the estimating mechanism as HOURS instead of SP during the in progress stage of project execution OR can it be done only for the issue type TASK alone.

What could be the possible pros and cons of this change? 

Thanks

1 answer

1 accepted

1 vote
Answer accepted

You can't just change the measurement technique part way through a process, it makes a nonsense of your measurement.

You need to decide what you are going to estimate in, and stick to it.  Select story points or the time estimates or another numeric thing, set it in the board configuration and work with it.  Note that "1 story point = 4 hours" defeats the purpose of using story points, you might as well just use the time estimates directly.

As for sub-tasks moving between sprints, they technically don't, individually.  The story they are in is what you're estimating on, committing to and hence the thing that goes into a sprint.  If sub-task is not done within a sprint, then, by definition, its story cannot be complete, so the story goes into the next sprint.  And hence all its subtasks go into the sprint complete or not.

The main con of changing estimation methods during a process is that your current numbers become useless and you might as well throw away all your estimates and reporting.  I can't think of a single pro for it.

@Nic Brough -Adaptavist-  Thank you for the quick reply. It make sense totally. 

Can I understand why 1 story points = 4 hours equation is defeat the purpose ? Just for the clarification. 

Also, can you suggest me a better way of capturing the smaller activity (which I mentioned on my question section) in JIRA within my story point configuration limits please. 

There's lots of reasons, but the two that stick out for me are:

You're supposed to be measuring relative estimates

Imagine my squad has a script to write.  We can't estimate it in hours.  I'm ok with scripts and would do it in 4.  My colleague who is much better than I am at scripting can do it in 2.    However, if you do it in story points, I can confidently say that when we have an estimate of 8SP, that task is twice as complex as a 4SP one or half that of a 16SP one.  It doesn't matter who eventually does it, we're measuring the relative difficulty. 

There are times when you definitely can do time estimates.  In which case, use the original estimate as the metric, don't bodge it with Story Points, you're just misrepresenting what you're doing and the estimate field is more useful for the way you are working.

Have a read through https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating and https://medium.com/serious-scrum/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7

The second one of these deals with how to deal with your smaller tasks too.

Like Deanna Velasco likes this

Quite helpful.  

Great explanation with links to learn further.  Thank you.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events