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,461,958
Community Members
 
Community Events
176
Community Groups

Backlog view - remaining estimate instead of original estimate

Hi,

I saw something like 3-4 people asking to show the remaining estimate instead of original estimate in the card layout of the backlog view. all of them got the same answer - you can go, and configure additional fields as part of the card layout configuration.

But as I see it - 

  1. This makes the card really thick and makes it not-readable. I avoid adding anything to these cards
  2. It only makes it more confusing, and its barely noticeable (for example, in one of these threads the user didn't even see that it was added after configuring it
  3. It only shows it on the bottom, which makes it really hard to do summaries etc

In my 2 last workplaces I had the same issue, and I am struggling to understand if there is a good reason for not having this option.

As I see it - when I do sprint planning, I don't care how much it was originally estimated, I only care how much work is left to be done. if this was a 2 weeks task originally, and I am only missing 5 hours, this will account for 2w, and won't allow me to plan correctly the velocity of the teams.

So - is there a good reason I am missing? and if not - is there already a features request to do this? 

1 comment

So your question makes perfect sense, but there's one thing that jumps out:

>when I do sprint planning, I don't care how much it was originally estimated, I only care how much work is left to be done

That is right and wrong at the same time.  When you're doing the work, you're absolutely right that you only care about what work is to be done.  But you said "left to be done".

In Scrum, the process is that you create the item, you estimate it, you select it for a sprint, and when that sprint happens, you complete it in the sprint.  An item is either done, or it is not.

There is no "left to be done" - you do all of it, or you do not.  Items should be completed within a sprint, and when they do not, then you take the entirety of it into the next sprint.

In other words, the amount of work left to be done is the original estimate.  

Well I think that it theory that's great, but at least for us, and that goes to all places I worked for, sometimes you are unable to complete something in the same sprint. either because something more urgent came up in the middle of the sprint, and you had to shift resources, or because the original estimate wasn't correct to begin with, or for many other reasons, and it doesn't always make sense to break the tasks to more and more small chunks... so I am left with tasks that have a different remaining estimate than the original estimate. mostly a lower estimate, sometimes even a higher estimate.... 

Like Kelly Kuzemchak likes this

Yes, I know, things do clock over into the next sprint when they can't be completed.  But velocity is not measured in pieces, it is measured on done or not-done.  The remaining estimate is irrelevant when you're doing Scrum and using sprints.

Thanks again for taking the time to answer!

I guess it's a point of view. but if a team was able to "finish" a 3w task, that actually took 4h because 90% of it was was completed in the previous sprint, it's ruining the statistics

and again - it's really hard to plan things like that. so I still try to understand why this is not available - is there anything else I am missing, or is it just something that did not get enough priority?

Nope, it's not ruining the statistics, it's doing Scrum properly.  It's not available because Jira Software is a Scrum tool.

Well since you agreed that sometimes things slip from sprint to sprint, I can't see how these two answers can live in the same world. I think it's not good, and according to the number of times it was asked in the community I assume I am not the only one....

 

Um, what two answers?  The only answer here is that you are doing your sprint estimates incorrectly, and the software doesn't support it.

This sort of question comes up regularly, always asked by people who are not doing scrum, but asking a scrum tool to support them.

Nic, are you answering in the name of Atlassian, or in your own name? 

@Nic Brough -Adaptavist-not everyone work according to Scrum, so while your theory is correct it does not solve the problem the majority of project based companies with little to no ideation work are having.

@Ron GrosbergEstimation in general is poor in Jira, and the reason is that it is built around arbitrary values that represent time slots, even if they have time based options as well.

We have asked for changes for a decade now about estimates and how they are shown, not just for remaining estimates, but also for subtasks, and so far Atlassian have ignored those requests. Not because they don't see the value, but because it would take Jira to be more than just a Scrum or Kanban tool, which open up all kind of problems for them.

It would not be very difficult to add the same 3 dots as the sprint have to each card (original, logged time and remaining time), but since that would only work for time based setups it is not a priority and probably never will be as the standard is story points that are binary.

Like # people like this

Hmm.

>everyone work according to Scrum

Of course they don't.  My point here is that you are trying to use a Scrum tool to support a not-Scrum process.  

>Estimation in general is poor in Jira, and the reason is that it is built around arbitrary values that represent time slots

This is called Scrum - everything in Scrum is timeboxed, and your estimates work within that.  I'm not sure what you think around estimation is "poor" - you can put estimates into Jira in many different ways, and it all works fine, Scrum or not.

"My point here is that you are trying to use a Scrum tool to support a not-Scrum process. "

Sadly, Jira is not used as a scrum tool for most situations. It is just the limitations placed on the users because the tool is built around a ritual that don't fit the majority of situations.

This is why you have so many requests to get around the limitations of Scrum and Kanban, so it works for more than those rituals.

Also, Scrum is not a process, it is a ritual.

Development is a process. Test is a process. Both are part of a build process that is part of a strategic value creating process.

Scrum changes nothing about the processes, it just changes the rituals within the lowest processes. This is why it does not scale and why teams almost always become isolated silos.

Again, the fact that most people don't work according to scrum does not change that many still are forced to use Jira as a company decision from management that don't understand what Agile is and what work the people in their organization actually do, does not matter if people ask for help to solve the situation they are in.

 

"This is called Scrum - everything in Scrum is timeboxed, and your estimates work within that. I'm not sure what you think around estimation is "poor" - you can put estimates into Jira in many different ways, and it all works fine, Scrum or not."

Your opinion, not mine. And not the opinions of a lot of other people that need to work within the limitation of finance and thin that Jira actually work for that out of the box. Jira is built around Agile guesstimating in arbitrary values like story points. This is why simple things like what @Ron Grosberg  ask for is not easy to solve and why subtask estimations still don't show up in the Scrum board.

This is probably also why there are no resource management or planning tool that actually work with individuals time and assignments. Agile also don't deal with skills as everyone is generalists as opposed to T skilled or specialized I skilled, so that does not exist in any tool either.

Again this goes back to Jira being an Agile tool, while most of us don't work with ideation but in projects, line organizations and maintenance where you have all three sides of the triangle locked in and tied to a budget and strategic planning. Or need reporting in values that are not made up that they can actually use across the company as a whole in a portfolio or strategic measurements.

This has been the case for over a decade, and nothing is going to change that. Atlassian will either adapt or another tool will fill that void. Until then, people will ask for changes that fit with how they actually work, and we will try to find hacks and workarounds to make due.

That is why we get questions like this. How do I make an Agile tool work in a global setting or in a project setting with fixed scope, time and cost.

So let's try to help those people do the best they can of an Agile tool that they are stuck with.

Like Ron Grosberg likes this

Ok, this is one where we're going to have to agree to disagree.

It seems to me that you don't quite understand what Agile does or why, nor what Scrum is for.  Y

ou are absolutely right that most people are not Agile, and there's a problem there in that Jira is built to be an Agile tool (at least for Scrum and Kanban directly, and a lot of the settings allow for other Agile methodologies, and for scaling them up too).  This, of course, means people who are pretending to be Agile have problems using it because they have not quite grasped it.

Our transformation and DevOps teams had a look over our (allegedly) Agile clients a few months ago, and came to the conclusion that over 50% of the ones who claimed to be working in an Agile way simply were not.  For those who claimed that they had teams doing Scrum, it was 75% failures.   That's about the same as other analysis of the industry seems to report.

I have a pretty good grasp of what Scrum is supposed to be today and where it comes from. I also have  a good grasp on other rituals and how they affect different groups as I have 25 years of practical experience working in frontend development, design, test, requirements, portfolio, vendor, support and so on.

I think those numbers are very low considering that Agile is a ritual that only works for ideation where you actually CAN iterate. Going through the rituals does not mean you are Agile, and in my 10 years of teaching and building with the Atlassian tools, I have found a total of 2 teams that actually were Agile. One App team and one team working with design.

The rest worked with stiff Scrum or just had waterfall with standups. Some don't even get to that, and they just behave as an ad-hoc or chaotic mess where people get sick and/or leave because it becomes unbearable.

Don't get me wrong, I love both Scrum and Kanban for what they work best for: Ideation and continuous deliveries. This is where they truly become magical and creativity can generate some wonderful new products.

 

As an Atlassian expert, my job is often to find ways to make Jira work in a normal process and more importantly, how to uniform the work without constricting the teams to the point where they feel locked in. The holistic view is sadly missing in Atlassian's tools, so this is a bit challenging, but certainly doable.

 

Atlassian not just focusing on Scrum and Kanban would help, but I am not seeing that happening anytime soon :)

>I have a pretty good grasp of what Scrum is supposed to be today and where it comes from

So do I.  And the Agile manifesto that was written later and said "hey, scrum and kanban fit in really well with this"

 >I have 25 years of practical experience

I'll rise to that one. I'm several years ahead of you on experience, but I count the project I ran to connect two financial systems together in 1996 as the point at which I really understood computing in a business context, so I've only really got 1 year over you.

> Agile is a ritual that only works for ideation where you actually CAN iterate

Yes, yes, yes on most of that. 

Agile is not a ritual in itself (but certainly encourages rituals when you do it).  I know, I'm quibbling on language here.

But the rest of that statement is absolutely right.  Agile is utterly the wrong thing to do when you can't (or don't want to) iterate.

> I think those numbers are very low

I take them "with a pinch of salt" too - whilst the numbers Adaptavist gets from our clients are similar to the data available in public, our consultants report higher failure to do scrum or kanban or or or "properly" than that.

> how to uniform the work without constricting the teams to the point where they feel locked in.

Yes, yes, yes, again.  There's a balance to be struck here and I don't have a clue where it is.  The scale from micro-manage to do-what-works-for-your-team is very very hard to dance along.

>The holistic view is sadly missing in Atlassian's tools, so this is a bit challenging, but certainly doable.

I'm not sure it's missing, but I am sure it's hard to find.

 

> The rest worked with stiff Scrum or just had waterfall with standups. 

Oh, that just makes me want to find a decent pub or bar with some good beer/coffee/mocktails so you and I can clink a glass together in honour of those people who keep us in a job.

Like Jimi Wikman likes this

@Nic Brough -Adaptavist- Can you please confirm if answers coming from you are on behalf of Atlassian or yourself?

It is good to have this discussion but I have to say that I am frustrated by the fact that it goes into a "religious" discussion instead of a pragmatic one.

Atlassian's marketing says things like "Every team has a unique process for shipping software. Use an out-of-the-box workflow, or create one to match the way your team works."

But in  reality if atlassian finds it more important to spread religious views that do not correspond to reality instead of helping its customers achieve their goals, then this is not a company I would like to tie myself to.

And I have to agree that JIRA does a very poor job in the "big picture" of planning, that I find very important. and we spend a lot of money on add-ons that will allow us to plan more than a day forward. 

The Microsoft tools, for example, really suck in terms of UX, but they are much more flexible in terms of planning.   

Like Jimi Wikman likes this

By the way we are mostly doing scrum. but you still need to have some strategic planning to know where you are heading to, and you still get to these places where your estimates weren't accurate and tasks slip from one sprint to the other, which means we still need the "remaining work" to be able to plan the next sprint. so saying "that's because you not doing scrum" is not accurate.

Like Jimi Wikman likes this

Ok, so there's a lot of stuff I could pick up on and correct in there, but I'll pick on the easy one to keep it short.

I am being entirely pragmatic, not "religious".  Scrum does not work the way you are working, and you are not doing scrum if you think remaining estimate is the way to do sprint estimation. 

The pragmatic thing I have repeatedly told you is that Jira Scrum boards do not support your not-scrum thinking.  

Coming back to this just because I bumped into it, then I realized why I did not answer, I was afraid to say something I will regret

Your answer is both wrong and disrespectful/rude, as I see it it is a dangerous mixture. I will leave it at that.

Comment

Log in or Sign up to comment