Scrum Artifacts: Product Increment
The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
The final artifact of scrum is the actual product increment as it exists at the end of a sprint, with all of the stories in that sprint which met the definition of done incorporated. At the end of each sprint, the completed features that were worked on should be added to the product for the sprint demo. At that point, the product itself is an artifact of the scrum process.
A goal of the scrum process is to develop features in such a way that the product is in a completed state at the end of every sprint, so it could be released, demonstrated to clients for feedback, or used as a tool for testing. While it’s not mandatory for an organization to release the product according to the schedule of scrum, this goal allows the state of the product to be part of the iterative process of development, testing, evaluation, and innovation that scrum encourages.
Ownership of the product increments should belong to the release engineers in most organizations, and should be fully available to the product owner. For web and mobile projects, often the product increment is a live demo branch of the product, maintained in a secure but accessible location.
For teams doing continuous integration, the live site may always reflect the latest work done by the team. In these cases, the public site or app will be the product increment.
These are a lot of new terms to become familiar with, but getting comfortable with the names and features of the scrum artifacts is a good place to start when learning about scrum. In this chapter, we’ve gone over stories, product backlogs, sprint backlogs, scrum boards, definitions of done, velocity charts, burndown charts, and product increments. And with that, we’ve covered the mechanics of scrum for web and mobile development!
Now that we have a handle on the roles, rituals, and artifacts of scrum, it’s time for us to take a look at the scrum contract. What is someone agreeing to when they start to work as part of a scrum team? What does it mean to work transparently? How does iterative improvement change the way we approach problem solving? We’ll be discussing all these issues and more in the next section.