Initiating development work

All development work in Scrum must fit within timeboxed development iterations that have consistent durations, limited to a period of 1 to 4-week cycles called Sprints. The output of a Sprint is an Increment of functionality that meets the definition of Done, is useable without additions or modifications, and is, therefore, a potentially shippable product.

With the definition and refinement of the Sprint Backlog, the development team immediately gets to work starting to build the new Increment of functionality, consistent with the Sprint Goals. Ideally, the teams complete all identified work before the Sprint duration ends, and all completed work complies with the definition of Done.

Recall that Scrum is a framework that serves as a container for other engineering processes. Therefore, test-driven development, continuous integration, and automated testing all logically fit within the Scrum framework and help to ensure the quality of the software.

The Scrum artifacts created and refined within a Sprint include the product backlog and Sprint Backlog discussed in previous sections of this chapter and Increments. The term Increment represents the functionality and value of the product in its current state. An Increment represents the backlog items from the previous Sprint but built on previous Increments. Therefore, while the term Increments represents the current extended functionality of the product, it's also appropriate to think of the term as implying the sum value of the product through the implementation of product backlog items to date.

Within each Sprint are four primary Scrum events: Sprint Planning, Daily Scrum, Sprint Review, and the Sprint Retrospective. We covered the topic of Sprint Planning in the preceding section, so, now, let's take a look, in order, at the Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

Conducting Daily Scrums

Every 24 hours, the Scrum Team meets, ideally at the same and same place, to discuss the progress of the team in completing the work of the Sprint. These Daily Scrum meetings should be short and to the point, usually taking 15 minutes or less. The team does not address any issues in these meetings. Instead, the affected team members and other technical or domain specialists who can help to resolve the issue, take the conversation offline in a separate meeting.

Supporting the pillars of empiricism, the Daily Scrums provide an opportunity for team members to inspect their progress and adapt their work to address any issues. The team can also agree to take on more work if it appears the team will accomplish their Sprint Goals with time to spare.

In the spirit of transparency, executives, customers, end-users, and other stakeholders can join Daily Scrum meetings. However, the Scrum Master must make sure these folks do not interrupt the meeting. The goal of the Daily Scrum is to minimize waste in the form of extended meetings that do not directly support the work of individual team members in their assigned work.

Daily Scrums continue through the duration of the Sprint. At the end of each Sprint, the team conducts a Sprint Review meeting, as discussed in the next section.

Conducting Sprint Reviews

On the last day of the Sprint, the Sprint team meets with designated stakeholders and the Product Owner to review the work of the Sprint. This meeting is called the Sprint Review. All work is entirely transparent to the attendees of the Sprint Review. The attendees inspect the work to see whether there are any variances from the original Sprint Goal. The development team members may provide a demo of the new product functionality to prospective users of the software.

The Sprint Review is another form of transparency that allows users and customers to inspect the product to determine whether the new functionality meets their needs. If the new Increment of functionality falls short of expectations or the users have new insights on how the product can better serve their needs, they record that information for further review in upcoming product backlog refinement and Sprint Planning meetings.

During the Sprint Reviews, the Product Owner discusses the work completed in the previous Sprint and the value it provides. They also take the time to discuss current priorities in the product backlog and their future development and release plans. The Product Owner should address performance against the project constraints of schedule, budgets, resources, and quality. Finally, the Product Owner should provide new insights on market conditions, potential business, or customer opportunities and their impact on future development priorities.

The development team reviews their work over the Sprint and explains what went well and any issues they faced and how they addressed those issues. The development team should also provide a demo of the new enhancements to the Sprint Review meeting attendees.

All attendees can participate in the discussions on current priorities, market conditions, new enhancement requests, and future releases. Though no decisions should be made in the Sprint Review, the team should update the product backlog to reflect new backlog items and priorities. The information gathered in the meeting becomes an input into the product backlog refinement discussions and Sprint Planning events.

Before the team meets to plan the next iteration of work, they need to take some time to inspect the work of the previous Sprint. The Sprint Retrospective, discussed in the next subsection, provides a scheduled opportunity for the team to discuss areas where they can adapt to improve their work and remove impediments affecting their ability to complete their work.

Conducting Sprint Retrospectives

Sprint Retrospectives offer an essential opportunity to inspect and adapt the work of the team in light of new information and issues discovered in the previous Sprints. The team's ability to act is highly dependent on the willingness and ability of the team to be transparent in uncovering and discussing their work.

Building strong bonds and trust among team members is critical, as is safety in terms of not making things personal and understanding that discussed information is not ever used to attack other team members. The team is responsible for the work they complete as a group, and they must act and work as a team.

The Sprint Retrospective meeting should occur right after the Sprint Review meeting. The goal of the Sprint Retrospective meeting is to analyze what went well in the previous Sprint and what did not go so well and to discuss ways the team can improve the quality or performance of their work in future Sprints, starting with the very next Sprint. Holding off on scheduling this meeting will make it challenging to implement any desired changes in time to affect the new Sprint positively.

The outputs of Sprint Retrospective meetings are agreements on opportunities to improve the team, and action items to make those improvements. Note that it can take several years for a Scrum Team to fully mature. In the interim, the Sprint Retrospectives help the team to grow and improve in their joint capabilities. As they reach a high level of operation, the Retrospectives help to keep the team from backsliding into old habits or unproductive routines. They also help the team to recognize new opportunities for improvement, including the development of new skills.

The Sprint Retrospective is the last scheduled event in the Sprint cycle. Assuming the Sprint Goals were achieved, with the release of a new Increment of functionality that conforms with the definitions of Done, the output of the Sprint is a potentially shippable product.

Releasing potentially shippable products

At this stage of the Scrum workflow process, the team has developed a new Increment of functionality that conforms with the agreed definition of Done and achieves the Sprint Goals. Products at this stage are potentially shippable. When a development team fails to produce a shippable product, they create an undesirable situation where each new Increment accumulates additional work in progress that the teams must eventually complete.

In other words, if a development iteration has unfinished work, and the Increment does not meet its definition of Done, the team must add the work to a future Sprint. In the meantime, the accumulation of incomplete work makes the product more difficult to work with, and it becomes increasingly more challenging to locate and fix identified bugs. This lack of discipline causes a form of accumulated technical debt that delays delivery of new functionality, slows work down, makes development work more complex, and hides bugs and defects.

So, the objective of Scrum is to have a completed Increment of functionality every Sprint, conforming to the definition of Done and thoroughly tested. The Product Owner, based solely on business reasons, will determine when to release the completed Increments into production. But in the meantime, every Sprint Increment must stand on its own, fully deployable should the Product Owner decides to do so.

That's the end of the basic Scrum workflow. The team moves on to help the Product Owner to refine the product backlog and plan the next Sprint. Now that you understand the basic Scrum workflow, we'll turn our attention to understanding the impact of systems thinking and lean development in the application of both agile and Scrum-based practices.