1

I've read various questions and answers and I'm really struggling to setup up a Project/Sprint/Story/SubTask to get what we think we need.

In terms of long term planning I've sold my team on the idea of Stories, estimates in Story Points, then measuring Velocity in Story Points.

The stories, however, can easily be quite big; taking a week or more to complete. This is because a lot of the work is essentially "Research something, then document it and output some options and recommendations (with relative merits, etc)". That nicely fits with a break-down into various sub-tasks; different topics to research being separate sub-tasks, documentation of each topic also being separate sub-tasks, final options and recommendations being another sub-task.

Where we're becoming stuck is that a burn-down chart in story points is next to useless for us. We see nothing happen for a week or more, then suddenly a massive percentage of the work is completed. So, we read about using Story Points for estimation and then adding time-tracking. https://confluence.atlassian.com/agile067/jira-agile-user-s-guide/configuring-a-board/configuring-estimation-and-tracking

As far as we understand it, and we may be wrong, we want the following process:

  • Add a Story to the back-log, with a Story Point estimate
  • When we move that Story in to a Sprint, create sub-tasks and estimate them in days/hours (but don't change the Story's Story Point estimate)
  • As we work the Sprint, we log changes to Estimated Time Remaining on each Sub-Task
  • Use a Burn-Down chart to track progress, the target being 0 hours remaining by the end of the sprint?
  • Use Velocity based on Story Points to estimate capacity for future sprints

So far we have the Stories estimated in Story Points, and the configuration below for Time Tracking.

But we can't figure out how to set an Initial Time Estimate of the Sub-Tasks...

enter image description here

1

So first to answer your simple question: Why not set the initial time as a function of the story points of the task? Story points are meant to measure complexity, which often ends up matching somewhat with time. That will give you a comparable result sprint after sprint.

However in my experience as a consultant I found that you want to do as little manual tracking as possible. So instead of doing manual tracking to reflect on some board, focus more on the standup. The standup is supposed to be a mini sprint planning. A look at whether the current direction is going to take us to the sprint goal. So in that it makes sense to ask people if they're stuck(the classic "any impediments"-question). A subtask staying in the same status for a "long" time will be a very clear indicator that someone is stuck.

  • For velocity to be valid for measuring the size of the backlog, all story point estimates must be made under the sane conditions. That is, with reasonable clarity on the scope of work, but before intensive investigation. This means that we can't (won't) modify estimates during planning, etc, or recalibrate to factors that improve our degrade or velocity. As velocity changes with time the ratio between points and elapsed time will vary. We do not want to go there. Points are for velocity, that's where they're going to stay. (Continued...) – MatBailie Feb 6 '18 at 19:46
  • This leaves us needing to have a quantifier for the size of a sub-task, after we've broken a story down during planning. Jira doesn't play nicely with putting points in subtasks, but does have an option for tracking their time instead. The burn down charts can then be set up to track that measurement. We have that working. But, it relies on a field we can see that is empty, unfortunately we can't find a way to access that field to populate it. That's the question, how in Jira do I "turn on" the estimated time field, in subtasks. – MatBailie Feb 6 '18 at 19:50
  • I see I wasn't clear. I didn't want to say that you should use story points for sub-tasks. You wrote "But we can't figure out how to set an Initial Time Estimate of the Sub-Tasks...". My point was to set the remaining estimate to something like a * #storyPoints * b, where a is some constant that makes sense to you, and b is the percentage of the story completed by the sub-task. – Torben Andersen Feb 6 '18 at 19:54
  • B is not constant. Velocity changes with time for varying reasons. Also, my point is that there is no where available for me to put a time estimate on a subtask. That's the question, how in Jira do I "turn on" the estimated time field, in subtask. I don't need a formula to translate points to time, I need a place to enter the time (or instructions to administration on how to enable it). – MatBailie Feb 6 '18 at 19:57
  • 1
    Yes that is jira administrator setting. You can make a trial account and be administrator of your own full suite to learn and mess around. What I did at some point. Good luck! – Torben Andersen Feb 6 '18 at 20:18
1

When you create a sub-task, you can enter an initial estimate

You said:

Where we're becoming stuck is that a burn-down chart in story points is next to useless for us.

So, we read about using Story Points for estimation and then adding time-tracking.

But we can't figure out how to set an Initial Time Estimate of the Sub-Tasks...

  1. In the Create Sub-Task dialog you should see a field named 'Estimate'. Here you can enter your initial time estimate in hours for each sub-task. If you don't see the 'Estimate' field, you may be able to turn it on by clicking on the 'Configure Fields' dropdown at the top right corner.
  2. Once the Sprint starts, ask team members to enter the number of hours they 'Worked' on each task and the 'Remaining estimate' (regardless of the original estimate) in the Log Work dialog (see screenshot) for each Sub-Task. Jira Log Work for Subt-Tasks
  3. Go To Reports, click on 'Switch Report' and select 'Burndown Chart'. Select 'Original Time Estimate' for the vertical scale. Now you should see a Burndown chart in hours, using the Original Time Estimate as the baseline.
  • Thanks, this is exactly what we're trying to achieve. The issue is that there is no Estimate field, and I can't see a way to add it. Possibly this requires Jira Administrator privileges, I only have Project Administrator privileges. As I'm contracting for a monolithic organisation I won't get the privileges, but if I can find instructions to make this field visible, that may be sufficient :) – MatBailie Feb 6 '18 at 19:41
  • I edited my answer and added how to 'Configure Fields'. – Ashok Ramachandran Feb 6 '18 at 19:52
  • It's not in that drop down list either. Annoyingly "story points" is, but the desired functionality isn't available for subtasks with story points. The functionality for Time Remaining is there, but it's not a field avaliable to me in the configuration of subtasks. – MatBailie Feb 6 '18 at 19:54
  • @MatBailie If this is the answer you were looking for, can you accept the answer? – Ashok Ramachandran Feb 7 '18 at 18:19
  • It correctly understands my issue, but does not provide a solution. See my second comment – MatBailie Feb 7 '18 at 18:42
1

We see nothing happen for a week or more, then suddenly a massive percentage of the work is completed

Take a look at my related answer, here: https://pm.stackexchange.com/a/20367/25606.

Further, you note...

"The stories, however, can easily be quite big"

To me, the obvious solution is to break up your current 'Stories' ("Research this big thing") into multiple Stories (one per research topic). That way, your burn-down will be more consistent.

I'm reluctant to break a story down in to smaller stories where those fake stories offer no business value in themselves [...] What we want here is information on how this sprint is progressing. Acting as an early warning to a failure to deliver.

A fair point. In that case, however, if all you need is insight into the status of the Sprint, I question the need for the overhead of dual-estimation. Many Teams choose to estimate merely by number of Stories, rather than Story Points. Have you considered doing the same here, for SubTasks? Simply burn down the number of SubTasks, rather than their estimation. Provided your SubTasks have a relatively even distribution, this should work well.

  • The second half is just a typo, I'm going Story to Subtask only – MatBailie Feb 6 '18 at 17:19
  • I'm reluctant to break a story down in to smaller stories where those fake stories offer no business value in themselves – MatBailie Feb 6 '18 at 17:20
  • I disagree with burn down charts being to predict velocity. That's calculated out side of a single sprint's burn down chart. The velocity calculated over several sprints can then inform capacity for future sprints and inform the time to complete a back log. What we want here is information on how this sprint is progressing. Acting as an early warning to a failure to deliver. I don't care what unit that is in, but I do care about granularity. The coarse nature of our stories do make Story based burn down charts useless, to us, even though we do get and use Velocity from other sources. – MatBailie Feb 6 '18 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.