Non-PBI related tasks in sprint backlog
I tend to think product backlog as a list of customer stories. When implemented, these stories need to satisfy DoD to get delivered.
Now, there are a lot of other necessary development tasks, that are not customer stories, and can not meet DoD for PBIs. E.g. internal design docs, spikes, refactorings, test framework building, workshops, etc. Those are not necessarily related to any single customer story in PB, but still must be done to get project forward.
So, I believe those tasks are simply inserted into Sprint backlog in the sprint planning, or even during the sprint. As they eat some story points, they will reduce the Sprint forecast (which is OK, of course, as long as they serve sprint or product goals).
Any second opinions on this way of working? I have seen some threads around this topic, which seem unnecessarily convoluted :)
So, I believe those tasks are simply inserted into Sprint backlog in the sprint planning, or even during the sprint
That work may or may not be included in the Sprint Backlog at any point. It's up to the Developers how they manage and monitor it.
Those are not necessarily related to any single customer story in PB, but still must be done to get project forward.
The most important "project" in Scrum is the Sprint, because it allows empiricism to be established and maintained.
If work is necessary for the Developers to meet the Sprint Goal, then they ought to include that work in the Sprint Backlog. The Scrum Guide describes this artifact as "a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal".
I tend to think product backlog as a list of customer stories. When implemented, these stories need to satisfy DoD to get delivered.
That isn't the definition of "Product Backlog".
The Scrum Guide defines the Product Backlog as "an emergent, ordered list of what is needed to improve the product". The Product Backlog Items could be things that customers want, but they could also be related to users or perhaps even the developers. The only requirement is that a Product Backlog Items represents an improvement to the product.
Now, there are a lot of other necessary development tasks, that are not customer stories, and can not meet DoD for PBIs. E.g. internal design docs, spikes, refactorings, test framework building, workshops, etc. Those are not necessarily related to any single customer story in PB, but still must be done to get project forward.
You're right that those other things don't make good Product Backlog Items, but for some of them, there is a better way of thinking about them.
Why can't creating or updating design documents be part of your Definition of Done? If a Product Backlog Item reflects an improvement (which is a change) to the product, the change may impact something captured in a design document. Perhaps the design document could be updated as the work is done.
Why can't refactoring be part of normal, daily work? Consider the Boy Scout Rule - every change should leave the system in a better state than you found it. However, if you did need to capture the refactoring as a unit of work, I'd challenge the assumption that it can't be in the Product Backlog. Refactoring is a way to improve the product. It shouldn't result in user-facing changes, but it will improve the ability of the Developers to build and maintain the product.
Why can't spikes be a part of your regular refinement activity? A Spike is a technique used to get more information about work to allow the team to make informed decisions about how to implement the solution. Refinement is about breaking down and defining Product Backlog Items. It seems like you can use a Spike to help refine a Product Backlog Item.
Why isn't building and maintaining your test framework considered an improvement to the product? Your customers and users expect the team to be able to deliver a quality product. Testing is a technique used to ensure that the product meets the quality requirements and will satisfy the stakeholders' needs. If you need to do work to enhance your test frameworks and improve the ability to test and deliver tested, working product, that is something that can go onto the Product Backlog.
So, I believe those tasks are simply inserted into Sprint backlog in the sprint planning, or even during the sprint. As they eat some story points, they will reduce the Sprint forecast (which is OK, of course, as long as they serve sprint or product goals).
Inserting work into the Sprint Backlog is acceptable. In fact, the Scrum Guide even offers it as a suggestion for a team to keep track of process improvements that come out of a Sprint Retrospective. I don't see a reason why the team can't use their Sprint Backlog to visualize all of their work and make it transparent to all relevant stakeholders.
Any second opinions on this way of working? I have seen some threads around this topic, which seem unnecessarily convoluted :)
The most important opinion is that of the team. What way of working best helps the team to plan and execute the work, delivering value to stakeholders and incorporating feedback rapidly?
@Thomas
Why can't creating or updating design documents be part of your Definition of Done?
Yes, a design doc update can definitely be in DoD. But creating a new doc is naturally a one-off task in sprint backlog.
Why can't refactoring be part of normal, daily work?
Sure it can and should. But sometimes refactoring is a major task, separate from user stories, and then its place is in the sprint backlog.
However, I must add that when the need for refactoring can not be reacted quickly enough (say, within few sprints), I believe it needs to be put visible in the PB as a Technical Debt story so that it gets the attention it deserves. That helps avoiding cumulating Tech Debt. Seeing many Tech Debt items in PB is a warning sign that stakeholders can understand.
Why can't spikes be a part of your regular refinement activity?
Yes they may be that, but then again, unless they are trivial, they should be tasks in the sprint backlog as they hog lots of story points.
Why isn't building and maintaining your test framework considered an improvement to the product?
Usually it is not a delivered to the customer. If it is, then it belongs to PB. If not, it just litters the PB with tasks that stakeholders, customers or even PO do not understand.
In general, keeping PB clean from dev tasks helps in many ways: comms with customers and other stakeholders, progress metrics, backlog refining, creating sprint forecasts, to name few. It is also better aligned with Scrum intent of focusing on customer value.
Yes, a design doc update can definitely be in DoD. But creating a new doc is naturally a one-off task in sprint backlog.
I disagree. If your Definition of Done states that the design documentation must be updated to reflect the implementation but none exist, would the act of creating them also ensure that they are updated?
Sure it can and should. But sometimes refactoring is a major task, separate from user stories, and then its place is in the sprint backlog.
While I agree with @Thomas that refactoring should be a part of your daily work, I also see that sometimes technical debt can be a large effort to eliminate. But I also do not see any difference in a technical debt item than a product update. You say that they are "separate from user stories". Why? Aren't the developers that benefit from the elimination of the technical debt also "users"? Why do you have to capture the information in a different format?
Yes they may be that, but then again, unless they are trivial, they should be tasks in the sprint backlog as they hog lots of story points.
I have never worked with a team that put story points to a spike. Instead they will timebox the amount of time that can be spent on the research. Since a spike is usually to learn something that isn't known, how would you estimate how long that will take? Instead, put a limit on the time you are willing to spend. At the end of that time, inspect if you need more time and adapt accordingly by continuing in the current Sprint or in a future Sprint.
Usually it is not a delivered to the customer.
I would expect that to be true. But the absence of a test framework would be what I consider technical debt. Now refer back to the conversation about technical debt representation in the backlog.
In general, keeping PB clean from dev tasks helps in many ways: comms with customers and other stakeholders, progress metrics, backlog refining, creating sprint forecasts, to name few. It is also better aligned with Scrum intent of focusing on customer value.
I disagree with that entire statement. Why shouldn't the customers and stakeholders know that the product they are getting was delivered but technical debt was increased in order to do so? Why shouldn't they know that if they want to have a new feature, it would be best to eliminate a certain portion of technical debt first so that the feature is easier to maintain and enhance in the long run? Why wouldn't you want to include the efforts to make products more manageable, performant, stable in the forecast, especially if neglecting the work would make the solution less than optimal?
You say that the intent of Scrum is focusing on customer value. That is partially correct. The focus is on delivering incremental value of high quality. And there is also the focus on being transparent in the work that is needed in order to deliver. It seems to me that you are trying to find justification for hiding pertinent information from people outside of the Scrum Team in order to make everything look better.
It seems to me that you are trying to find justification for hiding pertinent information from people outside of the Scrum Team in order to make everything look better.
I do not really understand this comment. Hiding information? Looking better? What on earth are you talking about :D ?
If you really think that littering PB with dev tasks helps you communicate the status better, instead of keeping user stories and dev tasks neatly separated (but still perfectly available to any stakeholder), then ... good luck with that!
Having said that, when I have worked in a small startup team as PO, I did not care about these kind of issues either. We all knew all the stories and tasks, so it was just convenient (or lazy, or ignorant...) to have them mixed in the PB. However, looking back, it would have been healthy thing to do even back then to keep them separated. It would have given more focus.
Today, working with larger programs, I find that quite crucial thing to do.
Looking at the original Scrum book 2002, it says that tasks are created in the sprint planning and they are the sprint backlog. Nowhere it says that tasks are inserted into PB, so I do not know where this idea comes from. In the book, the role of sprint backlog is emphasized as the means for bringing transparency to the team's work. So your comment about "hiding information" by having tasks in sprint backlog is obviously not Scrum.
But Scrum has evolved, so may be there is some amendment somewhere that I have missed?
A lot has changed since the 2002 "Agile Software Development with Scrum" book (I am inferring that this is the one you are referring to).
The first official guide came out 8 years after that book (2010) and has changed a number of times since through empirical learning and adaptation with the latest version being 2020 Scrum Guide. Books are great, though they are point in time. There is value in also leveraging the latest Scrum Guide to pick up on evolutionary improvements.
I believe the last mention of "tasks" was in the original 2010 Scrum Guide.
There are only Product Backlog Items (PBI) now...
"The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum."
What constitutes a PBI is left to a team to decide with only some high-level guidance provided...
"The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."
Returning to Ian's earlier comment...
"That work may or may not be included in the Sprint Backlog at any point. It's up to the Developers how they manage and monitor it.".
If we put digital tools aside and think about how a team may manage work on a white board and with sticky notes, they may tack on any number of notes or other stickies or tasks or whatever works for them. They may also do this in a digital tool through sub-tasks (Jira) or comments or again, whatever works for them.
IMHO You oversimplify PB only from the perspective of "user", which seems to mean here someone that only consumes the product. However, thinking about it wider may be helpful for you to assess what may belong to the PB. For example, as a PO you should not only think about what is needed to improve the product from a user perspective, but also from a business (sponsors) perspective and others - that might be for example improving the maintainability of the product, or reducing the burden needed to test in. Basically, everything what is needed to improve the product belongs to the PB - if you need a better testing framework to improve it, so be it. The hard part of being a PO is to make a call about the order of a variety of things that are in the PB.
Think for example about a bicycle for a kid. Here you will have different needs from the user (kid), the customer (parents of the kid), the business/sponsor, and possibly also the manufacturer. Thinking only about the user will limit your ability to actually create a valuable product. It may end up being the most desired version by the user - i.e marshmallow bicycle, but it may also at the same time not meet the needs of the customer (i.e about safety reasons), the business/sponsor (i.e hard to sell, high cost of mass production), and the manufacturer (hard to streamline mass production, if even possible to produce it). As the user may want to have an extra whistle added, the most valuable thing would be actually to work on the alloy of that bicycle or reduce the number of parts required for breaking capability.
Here is quite a nice video about changes in the Tesla door handle with some engineer reflection on the overall approach to changes. It might be helpful to see it and reflect on our view of what improvement in a product is :)
Yes, a design doc update can definitely be in DoD. But creating a new doc is naturally a one-off task in sprint backlog.
I don't agree that creating a new design document is "naturally a one-off task". Creating a proposed design for a change would fit more closely with refinement. Ensuring that your design document describes the as-built system would be part of the Definition of Done.
Sure it can and should. But sometimes refactoring is a major task, separate from user stories, and then its place is in the sprint backlog.
However, I must add that when the need for refactoring can not be reacted quickly enough (say, within few sprints), I believe it needs to be put visible in the PB as a Technical Debt story so that it gets the attention it deserves. That helps avoiding cumulating Tech Debt. Seeing many Tech Debt items in PB is a warning sign that stakeholders can understand.
Your Product Backlog is not limited to user stories. The Product Backlog contains everything that "is needed to improve the product". If refactoring can't be done as a part of other changes, I don't see why it shouldn't be on the Product Backlog.
Yes they may be that, but then again, unless they are trivial, they should be tasks in the sprint backlog as they hog lots of story points.
You don't need to capture everything you do in the Sprint Backlog. Every Sprint, you're investing some time to improving the Product Backlog and spikes are one technique to make sure your Product Backlog Items are ready for development. Refinement - whether it's spikes or not - doesn't have to be on the Sprint Backlog.
Usually it is not a delivered to the customer. If it is, then it belongs to PB. If not, it just litters the PB with tasks that stakeholders, customers or even PO do not understand.
Not everything on the Product Backlog needs to be delivered to the customer. The definition of the Product Backlog is a "list of what is needed to improve the product". The work on the Product Backlog could be valuable to the team, internal stakeholders, customers, end users, or someone else.
If stakeholders don't understand the need to perform work like maintaining the test framework, there is room for educating them. I'm sure that the stakeholders have expectations about the quality of the product they receive. For the team to be able to deliver the desired quality, the team will have to invest time to develop and maintain development tools and frameworks. The stakeholders don't need to understand all the details, but should be able to grasp the needs of the team at a high level.
In general, keeping PB clean from dev tasks helps in many ways: comms with customers and other stakeholders, progress metrics, backlog refining, creating sprint forecasts, to name few. It is also better aligned with Scrum intent of focusing on customer value.
Transparency is a key Scrum value. Making sure that the Product Backlog reflects the work that the team needs to do promotes transparency between the team and the stakeholders and helps the team communicate what they intend to do and the progress that they are making.
Looking at the original Scrum book 2002, it says that tasks are created in the sprint planning and they are the sprint backlog. Nowhere it says that tasks are inserted into PB, so I do not know where this idea comes from. In the book, the role of sprint backlog is emphasized as the means for bringing transparency to the team's work. So your comment about "hiding information" by having tasks in sprint backlog is obviously not Scrum.
But Scrum has evolved, so may be there is some amendment somewhere that I have missed?
It's been 20 years since that book came out. The first Scrum Guide came out in 2010 (8 years after the book) and was revised in 2011, 2013, 2016, 2017, and 2020. In addition to the revisions of the Scrum Guide, we've learned a lot more about ways to effectively organize teams to take on complex work that were not known in 2002 but are also consistent with the Scrum Guide. Specifically in software development, we've had many advancements in tools, technologies, and methods that were not possible in the early 2000s. So, yes, things have changed a lot. Sticking to what people thought in 2002 is dangerous in 2022.
Since you are referring to a hard copy of the 2002 Scrum Guide, I want to make sure that you know the current Scrum Guide is always available at https://scrumguides.org/. You can find versions of it in multiple languages. If you want the English version, it can be found at https://scrumguides.org/scrum-guide.html. It might be the time for you to read the most recent version. The authors use constant inspection and adaptation just as they advocate for in the Scrum framework.
If you really think that littering PB with dev tasks helps you communicate the status better, instead of keeping user stories and dev tasks neatly separated (but still perfectly available to any stakeholder), then ... good luck with that!
I not only believe that, I have seen it in real life. I have had many stakeholder make statements like "I had no idea my request was so complicated to implement. I thought adding one more field to the screen would be simple." It is also good for the stakeholders to see the technical debt items, especially if you describe them in a way that shows how the debt impacts the product. I have never encountered any stakeholder that did not agree to things like improving performance, improving the customer experience, or streamlining work. Those stakeholders gained a new appreciation for the work that is done. They also became some of the best stakeholders I have worked with because they started to understand the iterative delivery approach and advocate for us to repay some of the technical debt.
Everything I state in these forums are my opinion. Just like everyone else. We comment based upon our understanding and experience. We are all empiricist. Empiricism is a core foundation of helping an organization to have the agility to adapt quickly. None of us believe that the things we say are the only way that things can be done. I have learned a lot from comments made by others in the same thread in which I have commented. I was hard on you in my original comments but I do not mean it as a criticism. I meant it as constructive feedback. In fact, I have shared some of your beliefs in the past, but over time I have found that my understanding and practices were not beneficial. I hope that you can take the things that we are all saying and use that as a basis to inspect your own beliefs and adapt them to the situation you have now. And if you ever want other's opinions, we will all be here to give you ours.
PBI = product backlog item. That means it could be a "task", story, defect fix, and ?????
As stated above it seems to be a team question to balance transparency and administrivia.