High priority process improvement in Sprint Backlog

Process improvements ought to be selected in a timely way, so as to maximize the empirical delivery of value Sprint by Sprint.

Where multiple teams collaborate, they should agree which improvements are most likely to enhance the value of the next integrated increment and are achievable. Each team should then action those improvements or their relevant contributions to their implementation. Bear in mind that the most useful improvements from a Nexus perspective are those which enhance integration capabilities.

What is meant by the word "process"? How does it relate to "individuals and interactions over process and tools"?

I would think "process" is used here as opposed to "product". I.e. an improvement to the way the team works should be found as opposed to an improvement to the product itself (which would belong in the Product Backlog).

I would think that the agile value of "individuals and interactions over process and tools" is sufficiently honoured. After all, in a Sprint Retro, it's the individuals that interact to find a process improvement.

What is meant by the word "process"? How does it relate to "individuals and interactions over process and tools"?

If a process exists, there are often ways it can be improved to make sure it doesn't harm individuals and interactions.

What is meant by the word "process"? How does it relate to "individuals and interactions over process and tools"?

The operative word is "over". That is why the Scrum process framework is minimally prescriptive, and a good agile implementation of Scrum ought to hold individuals and their interactions at a premium.

Thank you so far for the insights. Especially the very catchy "opposed to product" phrase sound very helpful to give an initial understanding.



As I understand, behavior is also part of the process, right? For example "inform your team about the state of your work, if you won't be in the next day" is part of process with focus on individuals and their interactions.

Great insights for sure.

Interesting. Why one would think improving process should affect "Individual and interactions". The manifesto only says what is valued more. It does not say that the other is not important as well. 

Also Scrum, I understood to be a process framework. In fact all the events could be loosely classified as processes. Within those, as well as backlog refinement we could be employing many processes (e.g . 5why's, programming styles, documentation if part of done, even communicate ion can be a process)

I think retrospective could be used to discover improvement opportunities for individuals (behavior, knowledge), Interactions, and processes.

While the behaviour and interactions need to also improve, I would think they are a little abstract, subjective maybe so we might find it difficult to set "done" attribute to it. Doesn't mean it shouldn't be done. It should definitely be done if discovered. (Eg I can say I have improved relationship with PO, while PO might not feel the same way.)

Process, on the other hand is easy to say "done" when it is easily visible (transparent), thereby giving opportunity for further inspection and adaptation. 

I think the addition of this into Sprint Plan definitely puts some visibility into the continuous improvement.

Great question though. I am sure there be other insights too.

@Amjad



So do I understand you right? You would not consider improvements on behavior and interaction as a possible improvement of process to put into Sprint Backlog? Because I would very well like to do so. Of course, "done" might be a little difficult to apply here, but for sure not impossible.

So essentially back to the initial question of "What is meant by the word process?" Improvements in deployment process, the way to organize the product backlog refinement, changes to estimation practice, the behavior of handing over your stuff if you're off the next day or even using less curse words in emails could all be items people come up with as an action item for the Sprint Backlog. Where is the line to be drawn? Should there be a line at all? Are all examples legit process improvements?

Thank you Steven, 

Would you consider your examples as behaviour or part of process? I think those could all be part of process. 

"At regular intervals the team reflects on how it can be more effective, then tunes and adjusts it's behaviour accordingly"- manifesto

I don't think the scrum guide asks for done like I said, but you would have something on sprint backlog, that will need to be discussed at some point as being addressed. Sprint will come to an end...

Interesting. I am also thinking about this. 

Behavior to me is actions. I agree since some actions can be part of process they could go on sprint backlog...but there are other behaviours/ actions that might not be part of process, they need to be improved right away...why even wait for retrospective...(e.g. doodling around when my work is done instead of picking something else or other such)

However if the behaviour is part of the process, it might be a little more involved so it makes it to retrospective. But I agree where behaviour is part of process like all your examples, I think they make candidates for inclusion in Sprint Backlog.

Everything that generates waste or hinders transparency, inspection and adaptations are candidates for improvement. I don't know if we could draw a line except to look at whether it is defined earlier as part of some process or left as assumption. Very difficult. 

So I did a search on "process". Google describes process as "a series of actions or steps taken in order to achieve a particular end" 

If I substitute "actions" above with "behaviour". Would that make a little clearer which behaviours are bound to a process? But I a process has steps also...so if we eliminate a step or change a behaviour it would affect process. 

Process could also imply technical items..."constant attention to technical excellence and good design promotes agility".

I am just unsure about the reasoning as anyone but I am speculating what it might mean so apologies in advance. Maybe we should have a q&a forum of sorts with the scrum guide custodians.

Thank you for sharing those very valuable thoughts. I really liked that substitution of action and behavior, as it kinda points out quite clearly that behavior can almost always be seen as part of some kind of process to get things done.

In this way, you could even say that kind of everything can go into Sprint Backlog, as long as it helps the team to get stuff done in a better way, which means that the process of doing gets improved.

I found this a bit of a strange addition to the Scrum Guide. Obviously, the Scrum Team has to improve, but my Retrospectives usually have some result that would practically update the Working Agreement.

Example given, a problem raised was that the Daily Scrum was a bit status-y. Getting into the why's and how's, the team decided we needed to host it a different way by switching who was plugging in their computer (remote team). 

That strikes me as a process improvement, and I guess it could hit the Sprint Backlog, but it's not really accomplishable. So, it'll just sit out there getting started at every day and not get closed. 

Not a hill to die on for me... But, thoughts?

Isn't the behavior an outcome of the process ?

With the same people, different processes (let's say Waterfall and Scrum) will induice different behaviors.

There is a discussion in our community over here:

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

The high priority process improvement seems to go straight to the sprint backlog. According to a workmate who recently went to a course, this sprint backlog item is not estimated. But there's nothing mentioned regarding estimation of this item. But to me this doesn't make sense in any case. Or is the reason for it not making sense, because it's not meant to be one of those "high priority process improvements"? How should this be handled?



Examples:

 

• Inform your team about your current state of work, if you're off the next day
  • Improvement of behavioral process
  • Not part of product backlog
  • Nothing to estimate?
• Try "Walk the Wall" instead of "3 questions" at Daily Scrum
  • (Possible) improvement to the implementation of scrum process process
  • Not part of product backlog
  • Nothing to estimate?
• Do research on a better way to speed up our build process
  • Only preparation of an improvement to the development process (so stricktly not even something for the retro->sprint backlog procedure
  • Not part of product backlog
  • Could be estimated, but should it, as researching new stuff is kind of regular work a developer does? Or should the team velocity for that sprint be reduced by a day or so?
• Improve the deployment process by implemented merge&deploy
  • Improvement to the development process
  • Not part of product backlog
  • Could be estimated. Should it?
• Add functionality to the product to display error log id to easier find stacktrace in the log
  • Improvement to the development process
  • Part of product backlog
  • Could be estimated. Should it?

Why shouldn't we ​​​​​​​estimate items that could be estimated? Why should we do so?

Any ideas?

The high priority process improvement seems to go straight to the sprint backlog. According to a workmate who recently went to a course, this sprint backlog item is not estimated.

It would not necessarily be estimated on the Product Backlog, but it is reasonable for a team which plans to achieve something during a Sprint to have an idea of the amount of work involved.