A development team wants to automate deployment and testing. How would this be placed in the Sprint Backlog? And, how does this relate to Scrum Goal? e.g. CI/CD could be large enough that it could encompass a whole sprint in and of itself.
2 Answers
There are different ways to handle it. My preferred approach would look something like this.
First, the work should be expressed in the Product Backlog. The work in the Product Backlog is the work that is necessary to improve the product. The INVEST criteria are a good way to decompose the Product Backlog items into small, independently deliverable chunks that can move the team closer to their desired end-state. If this is the primary focus of the team, this work may be related to the Product Goal, but it doesn't have to be.
It's important to express the Product Backlog Items in a way that make sense to stakeholders outside of the team. Stakeholders should be able to understand why it's valuable to take on their work. In the case of CI/CD, automated testing, and automated deployment, there would be an emphasis on reducing manual activities, preventing human errors during test and deployment, and improving quality by having more rapid feedback to name a few. This can help the stakeholders understand the ordering of the work and why they should invest in the team to take it on over some other work.
Once the work is brought into a Sprint, it may or may not be related to the Sprint Goal. Although the Sprint Goal is the primary objective that the team wants to achieve during the Sprint, not all work in the Sprint Backlog needs to relate to the Sprint Goal. The team would approach it just like any other Sprint work, pulling it into progress and completing the work.
If you work in a scaled context, there may be some other considerations. Perhaps one team can take on the work for a Sprint or two in order to create the foundational framework that is then available for the other teams to incorporate into their Definition of Done. If there's a shared service team for infrastructure or product quality, then this team may take on that work themselves in addition to providing their services. The same general approach of putting the work on the Product Backlog, ordering it appropriately with all of the other product work, and then pulling it into Sprints does apply.
answered Jul 27, 2021 at 18:05
-
1I appreciate the part noting "buy-in" for the stakeholders. I guess this comes under transparency...this is how the product is affected currently without CI/CD, and this is how the product will be affected with CI/CD.– pauljJul 27, 2021 at 19:25
-
"It's important to express the Product Backlog Items in a way that make sense to stakeholders outside of the team." - is it always important? The reason we talk to stakeholder is mostly because they know business. And CI/CD is mostly a technical aspect. If stakeholders don't agree we should spend time on it - we should still go ahead and automate deployment (as an example). And since we should ignore stakeholders if they disagree, why ask in the first place? These are busy people too, the more decisions you can make w/o their involvement - the more thankful they will be. Jul 27, 2021 at 21:13
-
@StanislavBashkyrtsev Yes, always make PBIs understandable to stakeholders. The Product Backlog is designed to give visibility into what the team is working on now and next. The Product Owner is the one ultimately responsible for ordering the Product Backlog, so you don't need to get stakeholders to agree to it. Making it visible, transparent, and understandable helps promote trust and collaboration.– Thomas Owens ♦Jul 27, 2021 at 21:26
-
Sure, make it understandable. But non-technical people can't have impact on these tasks. PO can decide priorities for business tasks because he understands business, it's his area of expertise, it's his role. But he can't have impact on technical tasks. You may explain these tasks if he's curious, but he also should understand that he won't be able to change it if he disagrees. It's not his realm. Scrum doesn't cover this topic. Scrum says that Product Backlog is always prioritized by PO. Maybe because Scrum implies that team always reaches peaceful agreements ;) Jul 28, 2021 at 6:01
-
1Maybe the conversation around the level of visibility the backlog should give to stakeholders or PO should be a separated question instead of a debate over comments? I'm struggling to see how this would directly influence OPs perspective on his original CICD question.– Tiago Cardoso ♦Jul 28, 2021 at 7:56
My preferred approach is to do a 'hello world' story. Pick something small or trivial on the backlog and decide that you will be delivering it using continuous delivery.
Inform your stakeholders that although they will see only a small amount of value from this story, it will be the first story delivered using continuous delivery. Help them to understand the value of this approach.
It may also be possible to split the introduction of CI/CD over a number of stories that are delivered over several sprints. Once again, explain your approach to your stakeholders. You might say something like this:
Story X will be the first story to be delivered behind a feature toggle. Let me explain to you why feature toggles are good...
Story Y will be the first story to be delivered using our new fully automated end-to-end tests. With fully automated end-to-end tests we will be able to...
answered Jul 28, 2021 at 7:32
-
Since this question is about Scrum, can you explain how this approach is consistent with the Scrum pillar of transparency? It seems like this approach hides work within other work, instead of making it "visible to those performing the work as well as those receiving the work". It also seems like it will make it harder to base important decisions (such as the ordering of work in the Product Backlog) without this transparency.– Thomas Owens ♦Jul 28, 2021 at 16:48
-
1If you were to hide what you were doing it would certainly be problematic. However, as I mentioned in my answer I would recommend explaining to the stakeholders exactly what you are doing. I don't believe it would impact on prioritising the backlog as again it would be fully transparent and done as a part of a collaborative decision with the stakeholders (and Product Owner of course). Jul 28, 2021 at 21:28