Using Scrum in the development process

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.

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 (usually two to four 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. 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 (one-two week), 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). Take place at 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 went bad during the sprint.
9. Team demonstrates the work done.
10. Sprint Retrospective: three hour time-boxed meeting. Usually scheduled to 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 went bad 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 any obstacles/impediments have emerged

Scrum KPI

Scrum metrics we used to measure success of scrum team and keep development on track. The metrics are focus on the delivering of software.

1. Sprint burndown: A sprint burndown report then 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.

‍