Using Scrum in Cloud Software Development

At CloudGeometry, we apply the Scrum framework across all our projects. A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. Scrum is used to manage complex software and product development, using iterative and incremental practices. Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements and produce a product that meets evolving business goals.

Cloud-native delivery changes how some of this plays out in practice. When infrastructure is defined in code and releases go out through an automated pipeline, the gap between a sprint ending and the increment reaching users can close to almost nothing. That makes the Scrum definition of "potentially shippable" less theoretical and more literal, but it also means the team has to hold a higher standard of done, because there is no manual release step left to catch what testing missed.

An agile Scrum process benefits the organization by helping it to:

• Increase the quality of the deliverables
• Cope better with change (and expect the changes)
• Provide better estimates while spending less time creating them
• Be more in control of the project schedule and state

Scrum in short

1. A product owner creates a prioritized wish list called a product backlog.
2. During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
3. The team has a certain amount of time — a sprint, typically one to two weeks — to complete its work, but it meets each day to assess its progress (daily Scrum).
4. Along the way, the ScrumMaster keeps the team focused on its goal.
5. At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
6. The sprint ends with a sprint review and retrospective.
7. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Fig. 1. Scrum development process

Philosophy Behind Scrum

Scrum’s early advocates were inspired by empirical inspect and adapt feedback loops to cope with complexity and risk. Scrum emphasizes decision making from real-world results rather than speculation. Time is divided into short work cadences, known as sprints, typically one week or two weeks long. The product is kept in a potentially shippable (properly integrated and tested) state at all times. At the end of each sprint, stakeholders and team members meet to see a demonstrated potentially shippable product increment and plan its next steps.

Scrum is a simple set of roles, responsibilities, and meetings that never change. By removing unnecessary unpredictability, we’re better able to cope with the necessary unpredictability of continuous discovery and learning.

Scrum Roles

Scrum has three roles: Product Owner, Scrum Master, and Team.

Fig. 2. Scrum roles

1. Product Owner: The product owner is the project’s key stakeholder and represents users, customers and others in the process. The product owner is often someone from product management, a key stakeholder or a key user. The Product Owner is responsible for continuously communicating the vision and priorities to the development team. At the same time, Product Owners must be available to answer questions from the team.
2. Scrum Master: The Scrum Master is responsible for making sure the team is as productive as possible. The Scrum Master does this by removing impediments to progress, by protecting the team from outside, and so on. The Scrum Master does not manage the team.
3. Team: The development team is responsible for self organizing to complete work. A Scrum development team contains about seven fully dedicated members, ideally in one team room protected from outside distractions. A typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. In cloud-native teams this mix usually also includes platform or DevOps engineers, since infrastructure changes move through the same sprint as application changes. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. The team has autonomy and responsibility to meet the goals of the sprint.

Scrum Artifacts

1. Product Backlog: The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. It contains broad descriptions of all required features, functions, enhancements, wish-list items, etc. The Product Backlog defines the “What” that will be built.
2. Sprint Backlog/Sprint Scope: The sprint backlog is a list of tasks to be completed in a sprint. The Sprint Backlog is a forecast by the Team in sprint planning meeting and is about what functionality will be in the next Increment and the work needed to deliver that functionality. Sprint backlog is rarely changed in the sprint.
3. Product Increment: The Increment is the sum of all the Product Backlog items completed during a Sprint combined with the increments of all previous Sprints. At the end of a Sprint, the new Increment must be a working product, which means it must be in a useable condition. It must be in working condition regardless of whether the Product Owner decides to actually release it.

Scrum Time Boxes

1. Release Planning Meeting: used to establish a plan and the goals for all the stakeholders. In essence the meeting answers how we can turn the agreed vision into a winning product, meeting or even exceeding stakeholder expectations.
2. Sprint: a time-boxed iteration, typically one to two weeks, during which the scrum master protects the team from vision or scope creep that could affect the sprint goal. If a goal cannot be met, the sprint is aborted abnormally and restarted from the planning point.
3. Sprint Planning Meeting: a time boxed meeting (~5% of sprint duration). Takes place on the first day of the sprint.
4. During the first half, the team decides “what” to complete during the sprint from the product backlog and defines a sprint goal.
5. During the second half of the meeting the team decides “how” to complete the selected backlog items.
6. Sprint Review/Sprint Demo: a time boxed meeting (~5% of sprint duration). At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which the team shows what they accomplished during the sprint. Typically, this takes the form of a demonstration of the new features, but in an informal way.
7. Product owner identifies what has been done.
8. Team reports on what went well and what did not during the sprint.
9. Team demonstrates the work done.
10. Sprint Retrospective: three hour time-boxed meeting. Usually scheduled on the last day of the sprint.
11. Team inspects the last sprint in terms of people, process, collaboration, tools, etc.
12. Team reports on what went well and what did not during the sprint.
13. Identify actions that can be implemented in the next sprint to improve.
14. Daily Scrum Meeting: time-boxed 15-minute meeting, during which each member explains:
15. What has been accomplished since the last meeting
16. What will be done next before the next meeting
17. What obstacles or impediments have emerged

Scrum KPI

Scrum metrics measure the success of a scrum team and keep development on track. The metrics focus on the delivery of software.

1. Sprint burndown: A sprint burndown report tracks the completion of work throughout the sprint. The x-axis represents time, and the y-axis refers to the amount of work left to complete, measured in either story points or hours. The goal is to have all the forecasted work completed by the end of the sprint.
2. Velocity: Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting. The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the forecasted and completed work over several iterations–the more iterations, the more accurate the forecast.

Fig. 3. Sprint velocity diagram - Planned vs. Achieved scope

3. Epic & Release burndown: Epic or Release burndown charts track the progress of development over a larger body of work than the sprint burndown. Since a sprint may contain work from several epics and versions, it's important to track both the progress of individual sprints as well as epics and versions.

For cloud-native teams, these Scrum metrics are worth reading alongside delivery metrics such as lead time for changes and change failure rate. Velocity tells you how much the team completed; delivery metrics tell you whether that work reached production safely. A team can hold velocity steady while its change failure rate climbs, and only the second number reveals the problem.

FAQs About Scrum in Cloud Development

How does Scrum work in cloud software development?

Scrum works the same way in cloud development as anywhere else, with the same roles, artifacts and time boxes. What changes is how quickly an increment can reach users. With infrastructure as code and an automated pipeline, a sprint increment can go to production the moment it is accepted, so the definition of done has to include everything a manual release step would previously have caught.

How long should a sprint be?

Most teams run one or two week sprints. Shorter sprints give faster feedback and smaller batches, which reduces risk per release. Longer sprints reduce ceremony overhead but delay the point at which the team learns whether it built the right thing. Cloud-native teams tend toward the shorter end, since the release mechanics no longer justify a longer cycle.

What are the three Scrum roles?

Scrum has three roles: the Product Owner, who owns the backlog and represents the business; the Scrum Master, who removes impediments and protects the team's focus without managing it; and the development team, which self-organises to deliver the sprint goal. In cloud-native teams the development team usually includes platform or DevOps engineers alongside application developers.

What is the difference between velocity and delivery metrics?

Velocity measures how much work a team completes per sprint, which is useful for forecasting the backlog. Delivery metrics such as lead time for changes and change failure rate measure whether that work reaches production quickly and safely. They answer different questions, and a team improving on one while worsening on the other is a common and easily missed pattern.

Does Scrum still apply when releases are continuous?

Yes, though the emphasis shifts. Continuous delivery removes the release event as a meaningful boundary, so the sprint becomes a planning and learning cadence rather than a release cadence. The retrospective and the review stay valuable because they are about inspecting how the team works, which continuous delivery does not address on its own.

‍