Jira Kills the Sprint Backlog

Hey Kate, we r using gitlab but facing the same issues u mentioned above.

What r solutions to tackle the issue?

Get a clear answer from the stakeholder, that the user story is done or what tasks need to be done in order to accept the user story ?

If so I would move the UT to the next sprint with the remaining or new tasks?

For the velocity tracking I would mark a part of the story points done and re estimate.

What r ur thoughts?

A great article and what we need to remember is that "Tools are helping us in applying the process", but our misconception is that "The tool is the process".

Stakeholders will help you find out acceptance criterias, a list of things you should be able to check in order to say "yes this solution answers the initial need of the stakeholders".

Tasks are defined by the scrum team and usual well represent technical steps to achieve a solution that answers the acceptance criterias. If your story has been groomed properly, you can hope that there won't be additional acceptance criterias once you review the solution at the end of the Sprint. If the stakeholders are not happy with the solution, it can mean that there was a misunderstanding, or that suble but important details of the need have been missed. Depending of the gap, it can mean to add a new story, or to fine-tune with the existing story in some cases. If there were missing acceptance criterias, the team did not account for the additional work and perhaps revisiting the additional need with a new user story is the best approach.

Finally, you should perhaps avoid changing the initial estimate in support points, if for example the team did not complete the solution for the story by the end of the Sprint. That's because the exercise of doing an initial estimate is not the same at evaluating remaining tasks on an on-going work. When you do the initial estimate, the team will make assumptions of complexity and will have have unknowns that are both no longer there if you do re-estimate.

The team velocity should take into account the average sum of story points of the past sprints, so that any incomplete story will eventually be included in the average at a later Sprint.

Well, I don't think it is Jíra matter. Rather it is not good work of scrum master or coach. Planning in upfront is quite usual for strong project manager heritage. This is still just tool.
And we have to work with people, don't replace it with tools. Remember, to be agile and to do it are not the same.
Would be happy to discuss it with you once you would like too.

Exactly - it's the process-first, not tool-first.

This is exactly what I meant - if you let your tool (or its default settings as a matter of fact) run your process, you end up with a zombie process. Not having a good SM is one of the causes of this.
If you'd like to discuss more prompts like that, you can join me on LinkedIn, where I will be posting them 3 times a week 😊

Fred explained a lot of mechanics very well.
I would like to add few things:
After you end a Sprint all undone elements have to return to the Product Backlog, so that they can be reordered. If you fail to do so, you cannot assess if elements currently in the Product Backlog are more valuable or more urgent than ones carried over from the last Sprint.
Like Fred said reestimating (or updating to factual work) should be done only after an element has been Done (according to the Definition of Done) and partially done items don't count into the velocity.
If you feel you need some more information, feel free to connect with me on LinkedIn, I can explain over zoom and some coffee 😊

Aha, sorry, wrong interpretation. Once we understand each other then there is nothing to discuss here 😁. It is very common as a misconception. I fix it in my cases even not stopping over this and drive teams in right direction from early begin. Thank you for point this out. It is good to look around sometimes. And thank you for invitation.

My pleasure! I wish all Scrum Masters and coaches I met understood this 😁

JIRA is there to help streamline the Scrum process. It simplifies creating backlog, issues, and increments. JIRA also assist with tracking and highlighting progress, dependencies, and blockers.
If there is a failure, then it’s team not using JIRA correctly not a failure if JIRA. Asif Dada, Agile/Transformation Coach

This means every item in the backlog has a "business value" and after the sprint the undone items are orderd back in the backlog.
And than the top items are taken for the next sprint.
Is this correct.
Time seems to be a problem.
Some tickets get done in the last minute. Than comes the sprint retro, review. And next day the planing.
The last day of a sprint is often very stressful.

Seriously? The tool is the problem? Seriously? Lack of skills, lack of knowledge, laziness, incompetence...those are the things that are killing the sprint backlog.

Physical card wall is best IME. If that's not your case (typical), it does help to ponder the hidden/nuanced sacrafices the virtual analog makes for you.

JIRA does provide all these functionalities. All you need to know is how to use it. I suggest to have a scrum master who is well versed with JIRA functionalities. Most of the scrum masters do not know how JIRA APIs can be used to get reporting customized for their organisation portfolio etc. So it is not with the tool but with skills of scrum master.

Hi Kate.
I'm very interested to know out to handled the uncompleted work.
When we move the story to the product backlog then the sprint backlog is reduced although parts of the story have been done.
In this case it seems to me unfair for the team to not be acknowledged at all for that part .
What best approach do you suggest for this?

Thanks

ADO draws this distinction between Sprint Backlogs and Product Backlogs perfect right out of the box. In any event if the team is not versed in Agile and if there is not a well defined process any tool you choose will fail.

Don't let tools like hammer to hit your head :).. Nice...

What a nice tease, Kate. You found a problem outside of the realm of tools, injected it into them, and them told someone that tools kill. Pattern of an argument fallacy :-).

Our ultimate goal is to finish work. Undone work not only brings no value, but also makes planning harder (sometimes impossible) and leads us towards reducing quality. If we have no or little undone work in the end of a sprint, it will make the team go faster and in the more predictable manner.
Mechanism that only counts the element when it's completely finished makes the whole Scrum Team focus on finishing instead of starting new items. A role of a Scrum Master or an agile coach is to make them understand that it's not a matter of being punished or taking something away from them.
You can mark an item as partially done, but I would refrain from counting that partially done into sprint velocity (if you measure it). Velocity should measure things that have business value and are in a state of completion, this is how you get real measurements.
You can also not measure velocity at all and focus on more significant KPIs 😊

Actually this is great: you've uncovered an important impediment. Why are some elements finished at the last minute? Can we structure work, so that it does not happen or rarely happens? It's a great subject for a retrospective.
Usually a kanban board with a WIP limit will work very well here. Some teams decide to try swarming (working on only one element at a time as a team), some build a competency matrix which will help plan out work based on team competency construction.
I would recommend diving deeper in those common solutions and talking to your Scrum Team to solve it with them 😊

Exactly my point. Thank you for putting it in other words - hope that it will make it clear for more people! 😊

I simply adore intelligent people uncovering those tricks 😎
That was exactly the point - spark discussion, engage, make people think twice 😉

Yes, you have to have a tool suitable for your proces, not the other way around 😊

Bingo! Know your tooling, use it right, don't let default settings run your process for you.

I also like the physical board and if I'm colocated, I recommend that. But for any remote work you need a fully digital backlog...

Of course not - a tool is just a tool. You can use a hammer to put in a screw, but it will likely hurt you in the process. Choosing the right tool and using it right is the key - just like you said.
The tagline is supposed to spark thinking, conversation and clash opinions.
I hope that maybe someone that makes a decision for a 20 000 people company to use Jira on default, immutable settings, will think twice.

Having something by default has nothing to do. If we came reduce the complexity of the ma agent process by having some values set as default then we should.
From what you wrote tools like jira are causing all the issues but it's noy true.
Those default settings are the essence they are like daily scrum which by default is on the same day, at the same hour and in the same place. Is that a problem? No, because it is just a tool.

Thanks, mind flattered and ego manipulated ;) .. I am a bit concerned, though, that as these things bear the label of scrum.org, there will be lots of less experienced gurus taking your words straight to the heart and polluting the industry. The discussions below the post cannot fully prove otherwise. Would you care? :-)

P.S, And carving the nasty words into a picture.. this is going to be on the internet, Kate!! :-)

I took a lesson at explaining the background more than I did here. So next ones will be: carved nasty words, with more in-depth explanation 😉

Bingo :]

Actually it does. Remember that Jira is a project management tool with plugins/extensions for agile teams. And the majority of the world uses project management or falsely implemented agility. Their demand is higher and their needs prevail in building software that is fit-for-all. It's nobody's fault - it's the way market is structured and what the market wants. You need to devote time and people to set it up, configure and adjust to your processes. On top of that you need to be able to adjust the setting for each team's needs individually or give them the power to do so. Organizations just learning agility are not capable of doing eny of it - and it ends up in the tool driving the process, not the other way around.
Tools like Jira are excellent for managing many complex projects and products - it requires a lot of work to get them to work in your process, as every company and every team is different.
The majority of truly agile organizations use Jira for two things: time tracking (for software houses that bill hourly or daily) and Product Backlogs. They rarely or never used (and never mandated) the Sprint Backlog functionality, because it was too stiff. In fact they used tools like a physical wall, online collaboration whiteboards or excel files - these tools required way more energy to set up the way they needed and change as their processes evolved.

I can't agree. You're focusing on a tool and not on a root cause of problem. None of the default settings will force you to do something.
The true problem is related to people that don't think about their actions.
Tool is just a tool. If they can't use it or it's an obstacle the problem is not in the tool but in lack of understanding why they are using it. Saying that Jira is the problem is easy, but it's not the root cause of such problems

That's true - the root cause is the laziness, choosing the most popular, not the best suited tool. It's never a tools fault, it's its operator and that is what I wanted to point out in the comment earlier - going the short, not the right way. When you make that ill-motivated decision for the tooling for the whole organization, that tool starts killing Sprint Backlogs, self-organization and many other aspects of agility. But there always is someone that made that decision and is not aware/willing/able to change or acknowledge that. And teams suffer...

@kateterlecka:disqus I can't understand your approach. If you have a team / organization that understands Scrum very well it doesn't matter are they are using pen and paper, a whiteboard or jira. They are doing their job. Tool is not a problem. Tool can either speed up some things or slow them down.
The tool itself has no impact on the quality of the process or work they are doing. It's just a tool. It's supporting their actions.

When you make that ill-motivated decision for the tooling for the whole organization, that tool starts killing Sprint Backlogs, self-organization and many other aspects of agility.

It's not the tool that is killing Sprint Backlogs, self-organization or any other aspects of agility. Jira has nothing to do with the quality of Daily Scrum or how the team communicates to delegate their current tasks. Jira helps organizing the Sprint Backlog but will not force you to put there anything. Jira won't force you to plan 6 sprints ahead.

What cause all of those issues is lack of understanding why and how does it work. You can have the best tool in the world, the one that is perfect for you and your team, but as long as you don't understand why and how Scrum works it will not help you.

Tool will not do the the job for you. It won't improve the quality of the process, it won't make Sprint Planning better, it won't make your Sprint Backlog well organized. The tool is as good as the person that is using it. So as we know that it won't do the job for you (because it is just a tool) it will also won't break the process as long as you understand this proces. And we're getting back to my first comment.

It's not the tool tool, nor the default settings, nor the process automation that is causing issues you've mentioned. It's the people that have no idea what are they doing. They can destroy their Sprint backlog using Jira, whiteboard or anything else.

If I was Atlassian I’d sue you for slander for disparaging Jira in the title of your article. Jira has never impacted how I’ve prioritized a project or a sprint and in fact make it easy to slide around or quickly move to top or bottom. If you want to try to get all practitioners of Agile who you think are doing things wrong then focus on behaviors not tools.
And if you want to criticize Jira focus on what really fails like bugs open fir years or a lousy user interface with inconsistent controls. Or the fact that many basic features are upgrades that require expensive plugins.

What a lot of discussion and how confrontational. I've never had these reactions to my blog posts, especially about a tool, what is this?

A fool with a tool is still a fool.

It's not the tool.

Firstly, I don't consider jira as a tool for scrum. It's an enhanced tool of defect management and we'll marketed tool for scrum.

Unfortunately we have so many practitioners who doesn't understand the purpose and practices of scrum in the first place. For most of them it's still a process or method. I come across so many people who doesn't understand why the team size has to be around 7, why the sprint has to be 2 weeks, what are the expected cultural aspects.

Well said

Exactly, Jira is not the problem itself, it's not understanding what it is for and what it can do. Using it without thought is what creates problems. The real problem is organizations having a tool run the process, not creating the process and picking or adjusting the tool.

Controversy? 😁

If Atlassian asks for it, I will gladly change the title. But I believe they will understand that the title is one thing, but explaining that using the default settings and not adjusting to needs is the problem. This is one of the things they stress in their manuals, and good Jira consultants do the same.

Jira is a very handy tool for many teams I have worked with as long as they can configure it and adjust to their process and don't have to use the default or organization-imposed configuration. Just like mandating the use of Jira is counterproductive, saying you cannot use it has the same effect.

Well yes, apparently. But the subject is not identity, justice or politics - but Jira. You put up with- and engage all the comments, even the ones that seem to assume you're some sort of idiot. Which would be normal fare between a social media influencer and a teenage fan but is weird between Scrum Masters and a PST.

That's an interesting point of view. Let me give you mine. I believe replying to a comment is a form of respect towards someone that took their time to read and give my work some thought. I didn't write here for a long time. This is first of a series of posts I planned on releasing on my LinkedIn, but got invited to stretch to the Scrum.org blog.
I also believe that giving a subject to think about, possibly undermining our current train of thought is beneficial for growth - isn't it what a Professional Scrum Master class does? Fatburger (also pointing at a brand), the "Save the company". In fact all of the Professional Scrum classes have shocking and controversial items to talk about, think and change the direction of our habits to push us further. And IMO this is one of the things that differentiates Scrum.org classes and PSTs from just any trainer.

Sure, but the most controversial subjects in the PSM course are pretty hot topics around lying and ethics. They give you cognitive dissonance because you act against your attitudes. This seems a much too banaal a subject for that. Is it just people feel tricked? Is it that you are a woman? Or that you react to all the comments? Or is the Scrum Master version of the tabs vs. spaces debate? Or are people deeply personally invested in Jira?

How I wish my gender made anything easier, unfortunately it's the opposite (at least for business in Poland).
I this case popularity of the subject is its relatability. And it's not banal - it's costly and hard to solve.
Almost every corporate environment I worked with had a tooling problem - tools that are administered centrally, with no or little room for individual team adjustments and they fail to support their process needs. This is a wide and huge problem. There are teams in open conflicts with other departments because of tools. And it is an ethical problem as well - as a decision maker for the whole company who should I listen to? A salesperson who is easy to understand and will agree with me? Or my teams and risk conflicting opinions and need for deeper understanding (which costs me time and effort)? Or as a team, should I hate the tool? The decision maker? Or should I devote my time and effort to finding a better solution and proposing it? It's a widely known problem - very emotional and polarized. That's why it's popular. Understanding that it's not the tool's fault (individuals and interactions) brings us a step closer to understanding Scrum better.

I wasn't implying that your gender would somehow give a better discussion, rather that it might affect the tone of reactions, probably in an adverse way. I don't get very hefty reactions to my blogs and I salute how you've dealt with these threads.

After reading your comment I realize I've underestimated how much hassle tool selection/configuration brings and how little freedom others have. I've always been in the lucky position of either being able to choose a tool, ignore it, or at least configure it ourselves, I now understand that that is a luxury.

In fact this is the first article I wrote that has more than 3 comments. I wasn't expecting such a discussion, so it's a surprise to me as well. I hope that others from this series will spark as much thought and discussion as this one.

Thank you for the courage and openness to discuss such difficult and important aspects of this post - and I hope that you found something valuable for your future use. I definitely did learn from this thread.

Great article, Kate! I don't think you sould change the title of the post :-) We also collected four ways how a sophisticated agile tool can actually ruin the agility of a team. This is another great example.