Chapter
13
Deconstructing the Done Product Increment
It’s super important that everyone on a Scrum team knows what constitutes “done” for a specific project. Otherwise, you’ll end up having conversations like this:
- Product Owner:
-
Hey, I’m just checking in on the new shopping cart for our site. I had a customer ask about it, so I thought I’d see if it’s available for a quick demo.
- Development Team:
-
Of course, the shopping cart is done.
- Product Owner:
-
It’s done? That’s great. Let’s go ahead and deploy it early. This could really help on the next sales calls. Great job everyone!
- Development Team:
-
Well wait…we can’t deploy it. We don’t have the build scripts ready and the database changes are still being worked on, plus the unit tests aren’t complete yet…
- Product Owner:
-
You just said it was done.
- Development Team:
-
Well yeah, the shopping cart works locally—mostly. But it isn’t done-done.
- Product Owner:
-
Done-done?
- Development Team:
-
Yeah, that’s when we can ship it. Right now it’s just done.
And with that, the product owner and development team go their separate ways. Best case: both sides are equally confused about what just happened. Worst case: the product owner will never again trust the development team when they say that something is “done.”
Many teams struggle to create a done product increment by the end of each sprint. (An increment is the sum of all PBIs that were completed in the sprint, along with the sum of all product increments that were created in previous sprints.) They write code and they test it, but there are a lot of branches in the code repository that need to be merged. Then new code must be integrated and tested with previous increments, but all of that work seems daunting to accomplish in a single sprint while trying to add new features.
There are lots of reasons why teams end up in this situation:
-
New teams members join
-
Others leave the company
-
Developers are assigned to multiple projects
-
There’s no sprint goal
-
Sprint planning is poor
-
There were no refinement sessions during the sprint
-
Product backlog items are either too big or unclear
-
The product owner is absent
-
Impediments are piling up
-
Technical debt is slowing the team
-
The development team doesn’t have all skills it needs to deliver a done increment
-
Team members aren’t working together
In other words, all the Scrum anti-patterns in this book can—and often do—lead to a Scrum team that doesn’t have a done product increment at the end of the sprint.
It’s also possible that your team is new to Scrum and everyone is learning how to work in a new way. Learning is part of the game of Scrum. Sometimes the team has to fail in order to learn to deliver high-quality software. Failures give team members an opportunity to learn why they didn’t get to done during the current sprint, and they can make changes that will help them improve during the next sprint.
This type of question is what we in the training community call a Scrum Grenade. Often, the best answer to this question is a sly grin followed by “It depends.” Honestly, it doesn’t really matter: If you and your team are working toward adopting Scrum and are improving every sprint, don’t worry about whether someone thinks you’re doing Scrum. Just focus on creating working, releasable software as soon as responsibly possible.
The sprint retrospective is a great time to explore these opportunities to improve. As your team comes up with issues that prevented them from releasing a done product increment, refer to the appropriate chapter in this book to find some ideas of things to try next.
Your Scrum team needs to have available a tested, integrated, deployable, and usable version of your product at all times. The goal is to improve the increment every few days while keeping it in a ready-to-use—and potentially releasable—state. If the product owner wants to release the latest increment at a moment’s notice, that should be a low-risk and simple task.
Yes, this sets the bar high, but keep in mind that the development team creates and owns the definition of “done.” Having a done product increment every sprint is one of the central tasks required of a development team, so by using Scrum, the development team has committed to creating quality products and delivering done increments. The team is also focused on delivery and service to the product owner.
A good definition of done is transparent—it allows everyone on the Scrum team to know when an increment is done. It’s also specific to the development team’s situation and the skills that they have, which is why it’s created and owned by the dev team. If the development team falls under an overarching software development department or product development area, a definition of done may be created at that level. But then, each development team inherits it and makes it more strict to fit their situation and abilities.
The definition of done should be a list of qualities that describe the completeness of a product increment. For example, the definition of done could include “training materials completed for all features.’’ That way, when you tell the product owner and stakeholders that the increment is done, they’ll know that they’re looking at features that include the documentation the customer needs. By being open with the product owner and stakeholders, the development team can discuss improvement opportunities openly and work collaboratively to get better results in the next sprint.
Throughout this chapter, we’ll explore what “done’’ means, how your team can build a useful definition of done, and the characteristics of a product increment. As you’ll see, not having a shared understanding of done can cause all sorts of headaches. We’ll help you avoid these problems or, if you’re already dealing with them, suggest ways to improve your current situation.