Scrum Process: From Product Backlog Items to Shippable Product Increment

Table of Contents hide

The objective of the day-to-day work of a sprint is to create shippable product increment for the product in a form that can be delivered to a customer or user.

Within the context of a single sprint, a product increment or shippable increment means that a work product has been developed, integrated, tested, and documented according to the project definition of done and is deemed ready to release.

The development team may or may not release that product at the end of the sprint — release timing depends on the release plan. The project may require multiple sprints before the product contains the set of minimum marketable product (MMP) necessary to justify a market release.

To create shippable functionality, the development team and the product owner are involved in three major activities:

Elaborating

In an agile project, elaboration is the process of determining the details of a product feature. Whenever the development team tackles a new user story, elaboration ensures that any unanswered questions about a user story are answered so that the process of development can proceed.

The product owner works with the development team to elaborate user stories, but the development team should have the final say on design decisions. The product owner should be available for consultation if the development team needs further clarification on requirements throughout the day.

Developing

During product development, most of the activity, naturally, falls to the development team. The product owner continues to work with the development team on an as-needed basis to provide clarification and to approve developed functionality. During the Sprint, the team members:

Pair up development team members to complete tasks. Doing so enhances the quality of the work and encourages the sharing of skills.
Follow the development team’s agreed-upon design standards. If you can’t follow them for whatever reason, revisit these standards and improve them.
Start development by setting up automated tests. You can find more about automated testing in the following section and in Chapter 15. If new, nice-to-have features become apparent during development, add them to the product backlog. Avoid coding new features that are outside the sprint goal.
Integrate changes that were coded during the day, one set at a time. Test for 100 percent correctness. Integrate changes at least once a day; some teams integrate many times a day. Undertake code reviews to ensure that the code follows development standards. Identify areas that need revising. Add the revisions as tasks in the sprint backlog.
Create technical documentation as you work. Don’t wait until the end of the sprint or, worse, the end of the sprint prior to a release.

Verifying

Verifying the work done in a sprint has three parts: automated testing, peer review, and product owner review. The team can conduct:

Automated testing

Automated testing means using a computer program to do the majority of your code testing for you. With automated testing, the development team can quickly develop and test code, which is a big benefit for agile projects. Often, agile project teams code during the day and let the tests run overnight. In the morning, the project team can review the defect report that the testing program generated, report on any problems during the daily scrum, and correct those issues immediately during the day.

Automated testing can include the following: Unit testing: Testing source code in its smallest parts — the component level
System testing: Testing the code with the rest of the system
Static testing: Verifying that the product’s code meets standards based on rules and best practices that the development team has agreed upon

Peer review

Peer review simply means that development team members review one another’s code.

Product owner review

When a user story has been developed and tested, the development team moves the stories to the Accept column on the task board. The product owner then reviews the functionality and verifies that it meets the goals of the user story, per the user story’s acceptance criteria. The product owner verifies user stories throughout each day.

Summary

The development team reports on task progress by updating the sprint backlog with which tasks were completed and how much work, in hours, remains to be done on new tasks started. Depending on the software that the scrum team uses, the sprint backlog data may automatically update the sprint burndown chart as well.

Developing

Verifying

Automated testing

Summary

Leave a Reply Anuluj pisanie odpowiedzi