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
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.
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.