You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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.
The second one of these deals with how to deal with your smaller tasks too.