nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Time Management Fundamentally Broken - Let's help fix it.

JohnGalt1718

Jira time management is now worse than it used to be and it used to have major holes. Here's a list of all of the things that don't make sense, are downright wrong, or otherwise need to be fixed. Some of these are mentioned by other topics and requests but I'd like to get a central discussion going about a wholistic approach that fixes these issues and enables proper time estimation and management. Part one is the problems:

1. Original estimate on stories should automatically roll up the subtasks. By definition of a story has sub tasks, the story is the sum of the subtasks. You can't do this. You can't write an automation to do this either. And if you manually sum up all of the subtasks then the time remaining is all wonky too so you end up spending a ton of time just setting up time on a story for no reason. (i.e. you have to 0 out the time remaining on the actual story.

2. The loading information on the user avatar in the backlog that shows the total loading for that person for the sprint ignores original estimates on sub tasks assigned to them. Thus, there is no way to actually get a true loading report per sprint per user.

3. The User loading report is effectively useless because it doesn't tell you anything. I should be able to choose multiple users, and have it report on each user by user and by sprint and number of hours in that sprint estimated, and when looking at previous sprints it should show me actual recorded time compared to the original estimate.

4. Epic rollup of time is not correct and doesn't include a break down per assignee in the epic. I should be able to see the entire workload broken down by user in each epic and it should use sub task for estimates and show me estimated versus actual.

5. Adding original estimate and time spent to the lines on the backlog doesn't work because original estimate doesn't sum the sub items as outlined and the time spent ignores sub task time spent even if the checkbox is on.

6. I can't require PM/PO estimate on creation of a story. I can't require Original Estimate at commit. I can't require sub tasks on a story before commit.

Solutions:

I'm approaching this from a JIT methodology which works incredibly well to improve estimates and realistic timelines from beginning to end. This starts with Request, Accept and commit. request is the high level story written by the PM/PO that has as much detail as possible, Accept is the PM/PO asking the Assignee to Commit to the work. The Assignee kicks it back if they don't have everything needed for success. If they do, they sub task it, and estimate time. Once they're happy, they commit to the work that needs to be done.

1. Every story should have an Owner estimate. I can do this with a custom field, but I can't effectively report on it. This is what the product owner or project manager that is entering the work. This should be the left most circle on the backlog and on the active sprint. It's what I as the PM/PO THINK it will take my people. It is just time estimate for the story itself.

2. Every story should have an Assignee Estimate (Original Estimate). This works fine and I can even assign it to the circle on the backlog and the active sprint. But it doesn't handle sub tasks properly and should automatically update based on sub tasking if any. I.e. I shouldn't have to enter anything on the story itself in the vast majority of cases, the work comes from the sub tasks not the stories. This should just work.

2b. The story should have a break down of the original estimate by person if there is more than one person assigned sub tasks.

3. On every sprint I should be able to see from the backlog and at the top of the sprint the total loading for the period of the sprint for each employee. This includes across all projects over that same time period and should show me what is fuzzy if sprints aren't aligned between projects. This should include all time from estimates including sub tasks.

4. The employee loading report should be able to look both forward and back and specify the sprints to be included. If it's looking back, I need to be able to see the PM/PO's estimate, the original estimate, and how much time it actually took so that I can do retrospective at intersection and analyze why stories didn't get done on time or took less time so that we can better estimate the next time something similar occurs. For current and future sprints this is used to analyze resource availability so that I can right size my team. The better I get at time estimation top to bottom using this report, the more accurate my loading and as a result the better able I am to understand the resources I need to be successful.

5. Epics need to roll up all of the time properly. They'd don't right now and there is no useful time analytics on epics. We need this to be able to analyze these initiatives and properly cost out their overhead for profitability etc.

6. The backlog and active sprint need to show PM/PO Estimate, Original (sum of subtasks) estimate, and actual. It should show it on the right where the story points (useless) is. I know you can put in the original estimated, but this isn't enough.

7. The backload and active sprint need to show me the complete loading of each employee PM/PO projected, individual projected AND actual per person.

8. The user loading report needs to be drastically improved or a new report needs to be done that gets this right and is usable to be able to analyze all of this info.

If we had these things cleaned up, starting with rollup original estimates from the sub tasks; then proper sprint loading numbers per employee and optimally included the employee's time for this sprint and in all other projects too; then improved employee loading reports that let us retrospectively show this; and finally proper display of this on the backlog lines AND the Active Sprint view, we'd have a significant improvement that would allow teams to hit goals and better estimate time effectively.

Comments

Nic Brough -Adaptavist-

Ok, take a step back and look at the first problem, as that's a cause of a lot of the other problems

>Original estimate on stories should automatically roll up the subtasks.

It does.

But it does not do it in the same field because that would break time estimation in Scrum, and stop people who want to use sub-tasks to segment the work rather than accumulate from the lower level. And, of course, it would stop you putting estimates on issues themselves.

Have a look at the sigma fields - you'll find that ΣOriginal Estimate is the sum of the Original estimate on the issue and all the estimates on its sub-tasks.

JohnGalt1718

Well, I found this on the Card Layout, but I can't put these on the issue view on the right nor on the full version of the issue from what I can tell (they don't show up anywhere) and I can't put the sigma original estimate as the estimation field on the card nor row in backlog either. Nor can I add PM/PO Estimate for estimation as a secondary item.

So, it still doesn't work as you'd logically approach this if the story's estimate is the total of the estimates of sub tasks, which is what you'd logically want in Agile. Every story should have all tasks (and thus all time) sub tasked out as part of the assignee repeating back their understanding of the work that needs to be done and then tracking those sub tasks.

Nic Brough -Adaptavist-

Ok, it doesn't work in boards, no, but that's because the Software boards do not estimate on sub-tasks.

Kanban does not have estimates at all. You measure progress by throughput, which means counting cards, not looking at variable estimates (you could simply say something like "1 card = 4 story points, which is what one of my clients are doing in their scaled agile systems when a team chooses to do Kanban instead of Scrum)

Scrum has nothing to say about the use of sub-tasks really, but it does effectively tell you not to estimate on them ( in Jira ).

Jira considers sub-tasks to be a part of their parent issue, the are not sprint-able items in their own right. They're in a sprint as part of their parent, and do not contribute anything to the velocity calculation.

When you're planning and executing a sprint, you estimate the stories and deliver them. The sub-tasks are for the team to break up the story if it feels like it, but the important thing is that you do not commit to doing sub-tasks. You only do the sub-tasks as part of their story. Jira does not look at the sub-tasks when you're burning down or calculating velocity because the sub-tasks are not sprint items, they're fragments of one. You burn down when the story is done, and only look at the story's estimates.

(There's nothing wrong with putting estimates on sub-tasks, but if you're going to do it, you need a strategy for rolling them up, and just adding them up won't work the way you might think. Atlassian have gone with the most simple option - don't put estimates on sub-tasks at all, but it's not uncommon to find scripts or listeners that implement various ways to do it)

So, the Σ fields are the answer to a lot of the problem in plain Jira, but aren't the right thing to be looking at in the boards, because they can't work there as there's no summing strategy implemented in Jira.

JohnGalt1718

In my 20 years of doing project management for small and huge companies and doubling and tripling productivity (my smallest increase ever was 212% over previous 12 months), story points are a waste of time and contribute to slip because no one is actually teaching devs how to properly estimate work, the devs aren't rejecting the stories as written until they have everything for success, and the devs don't have practice getting better at estimation and understanding what they need to be successful with a story.

All stories should be the sum of their tasks that the assignee creates that reflects the work that was described in the story by the PO. This creates a reference check to ensure that the assignee actually understand the work that was assigned, and it creates a complete flow that shows actual work done at any given time and as a result of Request Accept Commit and JIT, you end up with accurate estimates (my devs are all within 10% of actual within less than 3 months of working for me), you know when is actually going to get done, there is virtually no slip without meaning as a result of horse trading based on company imparities, and you get what you actually asked for instead of a bad interpretation that you discover after the work is done. (And PS my burn down charts actually burn down instead of falling off cliffs at the end of the sprint.)

So while JIRA may be doing it the easy way, there is a better way!

Allow us to setup our issues so that their estimate is the sum of the sub tasks.
Allow us to setup PO/PM Estimates of proper time.
Allow us to show PO/PM versus Assignee Estimates
Allow us to see the rollup time recorded (which it does on the story level, but doesn't actually show anywhere else and thus makes it useless)
Allow us to report on all of this and see projected versus actual for all 3 along with delta as a percentage for each after the fact.

I have yet to see any project manager ever come close to the quality of deliverables and the speed of those deliverables that I do. And every PM that I train meets the same success. And I have extensive data collected when I helped the inventor of JIT refine it while he was mentoring me.

This is the fundamental failure of Agile. It can be better with JIT. But because of these basic problems in JIRA (and to be fair every other PM tool) it makes for a ton of repetitive work that doesn't need to happen. And the effort required for JIRA to make this work is not a lot and the result would be a superior product that if messaged properly could create a competitive advantage in a marketplace that is getting very crowded with competitors.

All JIRA has to do is stop blocking it from working the way makes logical sense and allow us to make one setting that makes the original estimate field on specific issue types as read only and be the sum of the sub tasks. And then make everything actually follow the rules everywhere else. I'd be fine if the estimate bubble on the right was only one, I can add it as another column, but when the story says to roll up the sub task time spent, and then doesn't show it anywhere but on the story as rolled up, that's a bug. And when the original estimate can't have the same option as the time spent, that's just illogical.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud