Guiding the flow of work in Scrum
The typical flowchart for Scrum looks quite different from traditional linear-sequential flowcharts of waterfall practices, in part due to the iterative nature of agile-based development practices (see Figure 3.1 – Scrum-based iterative and Incremental development cycle). Please refer to the following diagram to see the visual representation of the flow of work within each Scrum Sprint:
At the start of a Scrum project, the Product Owner must establish the vision for the product and create the initial product backlog of identified requirements. The vision holds until business or market conditions change sufficiently to warrant a revision. The Product Owner and Scrum Team continuously refine the product backlog to ensure the development activities stay in alignment with the highest value customer priorities.
Once the Scrum project kicks off, the basic flow of work within each Sprint iteration follows this basic pattern:
Begin a new Sprint.
Refine the product backlog.
Determine the Sprint's goal.
Plan the work.
Develop the Sprint backlog.
Conduct Daily Scrum meetings.
Conduct a Sprint Review.
Conduct a Sprint Retrospective.
In the remaining sections within this chapter, we will take a deeper dive into each of these Scrum events.
Establishing the product vision
Product development cannot begin until the vision for the product is conceived and articulated. The vision establishes the boundaries of a product. In other words, the vision specifies what's in and what's not in a product.
The vision of the product is not a statement of what it is but what it can be. The product vision refines our understanding of who our customers are and what value we will deliver to them. Moreover, the product vision represents a shared though high-level understanding of our value proposition.
A value proposition is a powerful approach to determining whether or not a new product or service is commercially viable. The information provided in a value proposition typically includes the following:
Product name and description
Target market customers
Challenges or needs addressed
Capabilities delivered
Benefits from use
Competitive advantages
Once the Product Owner establishes the vision for a product, the Sprint iterations can begin.
Implementing iterative and Incremental development cycles
Scrum implements an iterative and Incremental development process that starts with a product concept and vision and then Incrementally adds value through a series of iterative life cycle development workflows. Common with all agile practices, Scrum breaks the product development life cycle into a series of very short and frequent iterations. The objective of each Sprint iteration is to release a new Increment of functionality. Therefore, each Sprint in Scrum represents one iterative and Incremental development cycle.
All Scrum Teams follow the same iterative development cycles. In other words, the scheduling of Sprints across Scrum Teams should not be staggered. They are all contributing collectively to the creation of a potentially shippable product, contributing to the same Sprint Goals and all working toward the same definition of Done for the Sprint.
The Product Owner works with the Scrum Team members to prioritize and select high-value items from within the product backlog that contribute to a specific goal defined for the Sprint. This collaboration to prioritize and select items for upcoming Sprints is called product backlog refinement.
Conducting Product Backlog refinement
Through the process of product backlog refinement, the Product Owner works with the development team members to prioritize the development of features and functions with the highest value. The product backlog refinement process creates and finds the product backlog.
Product owners must determine the highest value features and functions that their product customers and users need. They must also work with the developers to determine the costs associated with developing and delivering new Increments of functionality. Also, there are technical requirements that support the implementation of user requirements. These technical considerations become part of the cost and timing factors associated with developing new product features.
As these factors come together for the highest value features, the Product Owner is in the position to prioritize the items in the product backlog. Following the concepts of the 80/20 rule, the Product Owner and Scrum development team members should not spend much time assessing the work involved to develop lower value features. Some of the lower value items may raise in relative value with the completion of higher value items or through emergent customer needs; but, until they do, the team should not spend much time assessing the work or scoping the requirements.
As part of the product backlog refinement process, the team must analyze each identified requirement to the degree that is necessary to understand the scope of work. There are many approaches to gathering, documenting, and analyzing software and systems requirements. However, within the agile community, the typical approach is to document requirements from the end user's perspective in a story format.
Creating User Stories
The Scrum Guide does not define User Stories as an artifact within Scrum. Kent Beck defined the term and this approach to requirements gathering in his book, Extreme Programming Explained.
Nevertheless, Stories are commonly used in Scrum as a natural language format to document customer and end user requirements. Likewise, themes and epics are not Scrum artifacts. However, Stories, themes, and epics are all commonly used within the Scrum framework to characterize and refine items within the product backlog. Collectively, these three classifications provide an efficient approach to documenting and organizing requirements as items within the product backlog.
In the context of Product Backlog refinement, User Stories provide the lowest level of abstraction necessary to define and prioritize work for an upcoming Sprint. During the refinement process, the Scrum Team collects additional information to understand the scope of work that's required. The refinement is complete when the Product Owner and Scrum Team can agree on a definition of Done for each item in the backlog.
Identifying a definition of Done
Another critical element of product backlog refinement is to ensure the team establishes a definition of Done for each product backlog item worked within the Sprint. Those who are more familiar with the traditional development model can think of the definition of Done as being analogous to acceptance criteria. In either case, both concepts share common characteristics, such as the following:
Each requirement should have clear and concise descriptions of what good looks like when correctly implemented.
The results of the requirement should be testable.
Everyone on the team needs to understand the requirement.
Requirements define capabilities that satisfy customer needs and objectives.
The definition of Done is situational to every product backlog item, refined by the Scrum Team members, and ultimately approved by the Product Owner. They must have a common understanding of what good looks like when a feature or function is fully installed and tested in the software or system. Also, there cannot be any bugs in the new code or the integration of the new code with the existing code.
In the last three subsections, you've learned how to refine a product backlog, develop User Stories that further refine the development team's understanding of individual requirements, and specify definitions of Done to help to ensure fulfillment of each backlog requirement. But we also need a method to decide what items within the product backlog should be considered for development within an upcoming Sprint. This process starts with the definition of a Sprint Goal.
Establishing Sprint Goals
Through the Sprint refinement and planning processes, the Product Owner and Scrum Team establish objectives for each Sprint in terms of the implementation of items from the product backlog. The Product Owner and the Scrum Team negotiate objectives and goals for the Sprint. While the Product Owner is accountable for establishing priorities, only the Scrum Team can commit to the work they can accomplish within each Sprint.
Sprint Goals are abstractions that sit above the level of User Stories and work tasks. Let's take a closer look at what I mean by this. If we are building an ATM banking application, we might have a Sprint Goal to build and test a set of features that allow bank withdrawals at an ATM. In this context, we might have two primary User Stories:
"As a user of the ATM banking application, I want to see my account balance when I log in so that I know whether I have sufficient funds to withdraw money for my personal needs."
"As the user of the ATM banking application, once I see my available balance, and assuming I have sufficient funds, I want to be able to withdraw as much as $250 from the ATM."
The Scrum Team defines the work tasks necessary to build these two features within the ATM application. Now the devil is always in the details, and there may be any number of other capabilities that might logically fit and support these two user requirements, such as having the ability to transfer funds between accounts before making a withdrawal and the ability to review pending withdrawals.
The Scrum Team negotiates with the Product Owner to determine which ancillary capabilities are of high value and critical for this release, constrained by the amount of work the Scrum Team can complete during the Sprint. Once they agree, the Scrum Team commits to deliver the negotiated and agreed features and ancillary capabilities within the Sprint.
Much of the work described so far is completed as part of the Sprint Planning event. Also, to the maximum extent possible, most Sprint Planning work is completed within a timeboxed Sprint Planning meeting, as described in the next section.
Conducting Sprint Planning meetings
At the start of the project and the start of each new Sprint, the development team analyzes the highest priority items or stories in the product backlog to identify the deliverable items within an upcoming Increment and how they will go about doing the work. This activity is referred to as Sprint Planning and is the first event scheduled within each Sprint.
The outputs of the Sprint Planning meeting and subsequent breakout sessions include a subset of product backlog items consistent with the Sprint Goals. The Scrum Team refines the agreed definition of Done and creates a list of work tasks and work assignments that are necessary to start building a new Increment of functionality. The sum of the identified work tasks forms the Sprint Backlog, which is necessary before development work can begin in the Sprint.
At the end of each Sprint Planning event, the team should be able to explain the following to both the Product Owner and Scrum Master:
The Increment of new functionality required to support the Sprint Goal
The scope of work the Scrum Team expects to accomplish over the Sprint
A clear explanation of how the team intends to self-organize and allocate their work
At this point, the team is ready to begin working on developing the new Increment.