The Scrum development method is a useful framework to help teams scope, plan, status, and demonstrate their work. When done well, it allows teams to get early feedback on the product they are building and provides a reasonably disciplined method of managing changes in scope.
By definition, however, a framework does not tell you how to do everything. The framework does not, for example, provide details on:
Eliciting, writing, and analyzing user and system requirements
Incorporating existing company practices with defined tailoring guidelines
Managing dependencies between teams in a large project
Using design practices to minimize design errors (such as interface, performance, and data definition issues)
Planning and executing testing activities that are needed beyond the scope of a sprint and analyzing the results
Collecting, organizing, and making available lessons learned and best practices to all projects when they start new work
If you are experiencing requirements, planning, quality, or customer problems, it might be a good time to add practices to solve these challenges or mitigate the risk of their recurring in the future.
There are many sources available for new practices. They can come from your existing organization or from classes, books, and Web searches. This article gives examples of adding practices from CMMI.
Adding practices from CMMI Level 2
In a previous article
I compared in detail Scrum and CMMI Level 2. There is a very good match between the two frameworks, Scrum being an example of how to implement approximately half of the practices of Level 2. The remaining practices of Level 2 that don't directly match a Scrum practice can be added to address challenges and risks in those areas (e.g., configuration management, measurement analysis, process assurance, and supplier management).
Adding practices from CMMI Level 3
CMMI Level 3 contains project management, engineering, and organizational learning practices that also fit well within Scrum (Figure 1). The following sections explain how they can be used. (A list of all the CMMI practices is provided here
Figure 1: Groups of practices overlaid with Scrum
In Scrum, the product owner creates a backlog of user stories, which, in their simplest form, are one-line statements that describe a user task that a software program is performing. Examples are, "As a user I want to generate a daily report with A, B, C information," or, "As an operator I want to track all attack aircraft aiming at me within a radius of N miles."
Although Scrum does not prohibit adding further details to clarify a user story, many teams stop at the one-liner and then discover the details as they write software and perform testing.
Requirements Development (RD) in CMMI Level 3 has three distinct sets of practices to improve backlog creation:
Develop requirements from the information gathered
These practices improve the skills of a team to gather requirements details from customers and end users; write them down in an organized fashion (which could be an extension to the backlog); and analyze them for errors, ambiguities, and feasibility problems. The result is a clearer understanding of the requirements before proceeding.
The practices of RD do not have to be performed at one time or be done perfectly in the beginning. They can be performed to build the initial backlog and then selectively repeated in each sprint as more is learned about the requirements from early sprint demonstrations.
Release planning, sprint planning, and daily stand-ups
Integrated Project Management (IPM) has distinct sets of practices to plan and manage a project. It includes steps to:
Plan using company-defined best practices and tailoring guidelines
Use organizational historical data for estimation
Identify dependencies and stakeholders for coordination, and comprehend this information into a master schedule or overall project plan
Manage the project with key stakeholders using thresholds to trigger corrective action (such as schedule and effort deviation metrics)
IPM is particularly useful when the project is large and has many dependencies and stakeholders. It provides the structure to make a large project manageable.
Scrum does have three aspects of IPM: the use of historical velocity data that can help a team make better estimates based on previous performance; Scrum of Scrums, which identifies other teams that need to be coordinated with; and retrospective data to identify lessons learned.
IPM, combined with Level 2 project management practices, provides a more complete set of steps for project coordination and tracking. IPM also includes two practices to take lessons-learned information from a project and make it available to the whole organization.
The primary aspect of risk management in Scrum is to assign features with technical risk to earlier sprints so that technical risk can be mitigated early. Technical risk is one source of risk, but not the only source.
The Risk Management process area (RSKM) is used to assess and prioritize all types of risks in a project and develop mitigation actions for the highest-priority ones. Example sources of risk are schedule, customers, technology, equipment, and suppliers. In RSKM, the project team starts with a standard memory-jogger list derived from previous projects and assesses what could go wrong in the current project. Risk management practices can be easily added to planning and tracking activities already performed in Scrum.
Tasks within a sprint
When a team performs sprint planning, it develops a task list called a sprint backlog. The content of this list is up to the team. Ideally, it is all the tasks required to complete the work committed for the sprint and results in a successful sprint review demonstration.
Many teams don't develop a task list and, instead, just start coding based on the user stories in the backlog. This approach is haphazard and introduces the risk of defects being delivered to the customer and technical problems that can cause overruns and schedule surprises.
The practices defined within RD, Technical Solution (TS), Verification (VER), Product Integration (PI), and Validation (VAL) are used to engineer the product to improve quality and product performance and to manage team time. They can be applied to the features being developed in a single sprint or to different selections of features as they are developed across sprints. Here is a summary of how the practices can be used.
RD (requirements elicitation, development, and analysis):
Generate, refine, and analyze the backlog
Analyze and validate specific requirements in each sprint
TS (design and coding):
Select among design alternatives
Perform design activities (see the short section below, What is design and when to do it?)
Code using organizational coding practices
VER (peer reviews and testing):
Peer-review selected documents and code to find errors early and quickly
Plan and execute component-level testing and analyze the results (e.g., defect density, pass rate, defect escape rate, and root cause)
PI (interface check, integration planning, and integration testing):
Plan and execute integration testing of components as they are completed, or when all components are complete
Check that interfaces are correct before system testing
VAL (end-user environment testing):
Plan and execute testing focused on the end-user's environment and needs
Analyze the results (e.g., defect density, pass rate, defect escape rate, and root cause)
Some Scrum teams do some, or many, of these testing practices as part of their test-driven development, code reviews, and daily builds. The practices contained within the engineering process areas of Level 3 make a team's performance more systematic, organized, and based on the best practices of the organization.
Organization learning and refinement
Scrum has a very good built-in retrospective step to encourage a team to look at what happened in the recent sprint and determine any process and tool changes for future sprints. When it does this correctly, a Scrum team improves its performance very quickly. This can be measured by less rework, fewer defects, and schedule accuracy.
The practices of Organizational Process Focus (OPF), Organizational Process Definition (OPD), and Organizational Training (OT) take lessons learned to the next step.
OPF (coordinated improvement):
Take what is learned at the team level and organize and deploy this information across the organization. The result is that all teams improve faster from the positive and negative lessons of others.
OPD (development of best practices and historical data):
Take what is learned at the team level and develop streamlined templates for the organization to use.
Develop tailoring guidelines to determine which practices and options should be used for different project situations.
Organizational Training (OT):
Assess, prioritize, and deploy training across the organization, including domain-specific, technology, and process skills needed to reduce errors and improve team efficiency.
Scrum is a framework and, by definition, does not contain all of the practices a project might need for different situations. Practices from other sources can easily be added, whether they are from existing organizational best practices, published frameworks, books, or models. When added with care, the intent of Scrum can be preserved.
What is design and when to do it?
Here is a short summary of "design." It isn't perfect, since design
is an ambiguous word and there are numerous opinions to choose from.
Design is a map of the system that can be used to:
Clarify and communicate concepts and definitions to other people involved in the project; this can cover architecture and detailed design issues
Identify potential sticky areas that need to be investigated and researched to learn what works and what does not
Find many (but not all) of the errors in a project earlier, at less cost than when developing the final product
Provide a common reference point for design decisions
Assess the impact of changes
The information that can result from design includes:
An architecture showing how the main components relate to each other
Interfaces to the user, to other systems, and between components
Data definitions stating what data will be stored and where
How constraints will be handled, such as design for testing, expansion, security, portability, and technology (e.g., PC-based, cloud-based)
Design information can be captured:
In textual design notes (e.g., a series of one-sentence statements such as, "The server responds every three seconds with X output," "Component Y will handle all system errors," or "Three databases will be used and synced every five minutes")
In graphical form (e.g., modeling languages, event tables, flow/timing diagrams)
As pseudo code -- a textual description of what the code will do so that issues and defects can be found and solved before time is spent developing code
In one document or split up based on the area being defined (e.g., placed in the header of each code file)
Design documentation is usually a hassle to keep up to date when design changes are made in the coding phase. You might consider developing architecture and design notes up front, reviewing them for defects and issues, and then updating changes to the design when the code is complete. The level of design documentation to keep, and where it is kept (e.g., separate document and/or code file header section) can be decided based on maintenance needs, ease-of-learning for new teams, and future enhancement plans.
Incorporating design activities
Incorporating design activities into Scrum while maintaining the benefits of Scrum is not difficult. The intent of Scrum is to deliver working code every sprint. This benefit can be maintained by changing the percentage of coding and non-coding activities in each sprint. Instead of each sprint being 100 percent coding and feature testing, start earlier sprints with a small allocation of feature-development time and front-load these sprints with other tasks, such as architecture design. For example:
Sprint 1: X percent architecture design, 100-X percent other sprint activities
Sprint 2: Y percent architecture design, 100-Y percent other sprint activities
Sprint 3: Z percent architecture design, 100-Z percent other sprint activities
For example, X = 80, Y = 40, Z = 0.
The earlier sprints can use the feature-development time for high-risk features, core product components, and features that will be needed to support later functionality. You can also back-load later sprints with system test, performance testing, and reliability testing when the time needed for feature development is less in later sprints.
You can select the percentage allocation for the sprints based on the need for that activity and the risk of not doing it. You might decide that design takes zero percent for low-risk projects or features, or that design has a large percentage of time allocated for the first three sprints to work on architecture, and much less from sprint four onwards.
If you have comments or questions, please email firstname.lastname@example.org