The Scrum Agile Process – Move forward with agility
As wise men say – “Never stop learning, because Life never stops teaching”.
Before you read through this, I would like to acknowledge that I am no writer & all that is mentioned here is an outcome of my recent training(s) & exposure of working with a Scrum Team. Hope this helps all those who want to run their current projects & team using Agile methodology.
Introduction
The purpose of this document is to walk you through a software development framework called Agile, its processes and its implementation via Scrum. It will help you understand ways in which you can introduce scrum processes within your team. For someone who has stepped into the role of a Scrum Master or Product Owner, this certainly will act as a support for moving ahead.
So, let’s get started….
Agile
Agile gives you a development methodology that helps you to develop software in an incremental manner. It allows people to collaborate together to achieve a common goal of delivering a high quality product that not only meets customer’s expectation but also meets the requirement at a sustainable pace.
Agile values:
- People Over Processes
- Working Product Over Comprehensive Documentation
- Customer Communication & Collaboration Over Contract Negotiation
- Responding to Change Over Following a Plan
Agile promotes a collaborative effort & contribution from people. It provides people time to analyse & retrospect their work and think about the next steps. This allows the teams to work as a self-sustainable unit.
What is Scrum for Agile
Scrum is an incremental agile software development framework. It can also be described as a management and control process that cuts through complexity to focus on building software that meets business needs.
Software companies had always achieved success when developing product based on Waterfall model. However as the IT world progressed, developing software changes mapping with the current market needs were part of the developing products. Waterfall & other subsequent methodologies failed with this changing environment since they never gave way to agility.
How does Scrum work
Scrum talks about timeboxing the development in a time frame. Timeboxing puts strict time boundaries around an action or activity. The minimum time boxed for a sprint (duration) is 2 weeks & the maximum time boxed should not go beyond 30 days.
It recommends developing software based on existing & changing customer needs; making a product that is prepared for the current market needs. Scrum also recommends shipping the product that comes out of a sprint to the customer for immediate feedback.
Scrum as a framework focuses on Customer’s needs & requirements even if it meant changing the existing plan of action.
Scrum Framework
The Scrum Framework solves complex & adaptive problems. It comprises of:
- Scrum Roles – Product Owner, Scrum Master, Development Team
- Scrum Artifacts – Product Backlog, Sprint, Potentially Shippable Product (Increment)
- Scrum Activities – Product Backlog Refinement, Sprint Planning, Daily Scrum. Sprint Review, Sprint Retrospective
Scrum Roles
Scrum propagates clarity in roles & team members. The scrum team has a slightly different composition than a traditional waterfall project, with three specific roles: product owner, scrum master, and the development team. And because scrum teams are cross-functional, “the development team” includes testers, designers, and ops engineers in addition to developers.
Product Owner:
- Understands business needs & works towards maximizing the ROI
- Creates product vision
- Responsible for creating & managing product backlog
- Ensures development team understands business needs
- Defines sprint goals
- Reviews & demonstrates the product to stakeholders before evaluation
Scrum Master:
- Understands the product vision
- Owns the process & coaches the team
- Helps in backlog refinement
- Facilitate the sprint planning meeting
- Helps team to create a sprint backlog & a goal
- Remove impediments
- Facilitate sprint review & retrospective meetings
- Acts as a change agent
Development Team:
- Understands the product vision
- Understands the product backlog
- Understand & commit to sprint goal
- Focus on technical excellence & engineering practices
Scrum Artifacts
Scrum Artifacts provide key information that the Scrum Team and the stakeholders need to be aware for understanding the product under development, the activities done, and the activities being planned in the project.
Product Backlog
- It can also be termed as an ordered list of requirements that are needed to build a product.
- This consists of Functional, non-functional requirements, enhancements, change requests, defects
- Each item in the product backlog is referred as “Product Backlog Item (PBI)”. PBI can be User story, use case, voice of customer
Sprint Backlog
- The sprint backlog consists of committed list of requirements that are needed to be achieving the sprint goal.
Potentially Shippable Product (Increment)
- Potentially shippable product increments in Scrum represent work of good quality that is potentially shippable to end customers at the end of a sprint.
Understanding Ownership
In scrum apart from sprint goal, the team’s responsibility is to up skill themselves so that the team works as a self-sustainable unit. However till the time this need is met, it is highly important that the team members understand the expectation that is from them. In this section we will understand the work & the ownership within scrum.
*Here Scrum Team refers to Scrum Master + Development Team
In scrum it’s important that we capture data & analyze it for the sprint to work smoothly. Usually, the PO & Scrum teams find it hard to close the timings of each activity. However scrum gives a formula to calculate the time that should be spent on each activity.
Scrum Activities
Scrum projects include five essential activities:
Product Backlog & Refinement
- The product Backlog is an ordered & emerging list of user needs plus anything else that is required to fulfill the Product Vision.
- As an owner the PO needs (in collaboration with the SM & DT) to refine the product backlog & make it ready so that the user stories can be included in the sprints
Sprint Planning
- During the first session the Product Owner presents the highest priorities of the Product Backlog to the team. The team and the Product Owner collaborate to help the team determine what functionality can be delivered in the upcoming Sprint. The team commits to this Product Backlog at the end of the session -Selected Product Backlog.
- During the second session of the meeting, the team plans how it will meet this commitment by detailing its work as a plan in the Sprint Backlog.
Daily Scrum
- Daily Scrum is needed to inspect the progress being made w.r.t the sprint goal & adapt the plan to get there
- Meetings are typically held in the same location and at the same time each day.
- The Scrum Master keeps a track of the progress within a scrum via the Burn down chart & calculates the team capability by measuring the velocity by the end of the sprint (based on story points).
Sprint Review
- The sprint review meeting in Scrum is an informal gathering where the scrum team shows what they’ve accomplished during the sprint.
- For a 2 week sprint the Sprint Review time should be 2 hours.
Sprint Retrospective
- The sprint retrospective meeting is a place to inspect the process, people, infrastructure, tools & adapt the ways & means to continuously improve.
- The entire team, including both the Scrum Master and the Product Owner should participate.
- The sprint retrospective can be placed for up to an hour, which is usually quite sufficient.
Understanding Story Point Estimates
All in software industry have burnt their hands at least once in Estimates. Estimates in general are rough calculation or judgmental calculation which is based on Man hours & Days. The way we estimate worked well for a water fall model however in Scrum, the focus is on the complexity rather than man hours. Scrum suggests Story point as one of the effective ways to estimate a user story.
Introduction to Story Points
Story point is a relative unit of measure that indicates Development Teams understanding of:
- Uncertainty
- Complexity
- Amount of Work
Why Story Points?
Main advantage is that humans and developers specifically are actually pretty bad at estimating time. Using an abstraction takes the focus off the actual time in hours or days and instead puts the focus on describing the relative expense and complexity of a task as compared to other tasks.
Typically when a story point is being provided to a user story, it is the Scrum Team that is actually thinking of the implementation, complexities & way of doing it right in the first time rather than an individual member. The concentration is less on man-hours, days & more on complexity as well as inter dependencies.
How to Calculate Story Point of a User Story – Planning Poker
Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, & the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
The reason to use planning poker is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants’ sizing. Planning poker should force people to think independently and propose their numbers simultaneously. This is accomplished by requiring that all participants show their card at the same time.
Burn down & Velocity
Burn down Chart
Progress on a Scrum project can be tracked by means of a release burn down chart. The Scrum Master should update the release burn down chart at the end of each sprint.
A burn down chart is a graphical representation of work left to do versus time. The horizontal axis of the sprint burn down chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint.The burn down chart is an essential part of any agile project and is a way for the team to clearly see what is happening and how progress is being made during each sprint. This is always plotted by the Scrum Master at the end of a sprint.
Measuring Velocity
Velocity is a metric that predicts how much work an Agile software development team can successfully complete within a two-week sprint (or similar time-boxed period). Velocity is a useful planning tool for estimating how fast work can be completed and how long it will take to complete a project. The metric is calculated by reviewing work the team successfully completed during previous sprints; for example, if the team completed 10 stories during a two-week sprint and each story was worth 3 story points, then the team’s velocity is 30 story points per sprint.
Generally, velocity remains somewhat constant during a development project, which makes it a useful metric for estimating how long it will take a team to complete a software development project. If the product backlog has 300 story points, and the team is averaging 30 story points per sprint, it can be estimated that team members will require 10 more sprints to complete work. If each sprint lasts two weeks, then the project will last 20 more weeks. If a team member is moved to another project, however, or new members are added — the velocity must be recalculated.
Scrum Agreement & Rules
There are agreements & rules that Scrum broadcasts. These are:
Scrum Agreements:
- Definition of Ready – It is an entry criteria agreed by PO & DT for items in Product Backlog before pulling them into a sprint.
- Definition of Done – It is an exit criteria agreed by PO & DT to consider a PBI (Product backlog Item) done & ready to be shipped.
- Cost of Production (DOWNTIME)
- Defects
- Over Processing
- Waiting
- Neglecting New Ideas
- Transportation (Hand Off)
- Inventory
- Motion
- Extra Features
- Cost of Delay
- Cost of Opportunity
- Relearn
- Rework
- Penalty
Scrum Rules:
- Time Boxing
- Scrum Teams adhere to the maximum timebox agreed for Sprint & activities
- Rules on Roles
- All the roles are peers, no hierarchy
- All the roles are exclusive & committed
This is all about the processes that can be introduced to build a great Agile Teams. Hope this helps you & your team in delivering Quality to the customers.
