Scrum is very popular, so popular that many think both Scrum and Agile are one and the same. However, the fact is, Agile is a philosophy that has 4 core values and 12 principles that are described in the ‘Agile Manifesto‘, and SCRUM is a methodology or framework that follows and implements this philosophy. There are many Agile methodologies and SCRUM is one of them, but it is the most popular Agile Methodology or framework.
Scrum gets its name from the analogy to Rugby, where a team work in a chaotic environment to keep control of the ball. This can be compared to a team working together in a chaotic environment to keep control of a project.
SCRUM consists of Self-organizing, cross functional teams (the teams consist of a group of people, who each has different areas of expertise, but work together for the same outcome). A Project Manager does not control the team members, as their expertise empowers them to make decisions collectively. The teams work in iterations, which allow businesses the flexibility to change the requirements, but still gives the development team the certainty it needs to deliver a working piece of product. This is one key thing that makes SCRUM powerful.
SCRUM THEORY & VALUES
Scrum is based on “Empirical Process Control Theory”(EPCT), which is based on 3 principles
- Transparency
- Inspection
- Adaptation
The idea is that the Scrum team should be transparent and honest in all that they do on a project. Being Transparent means – the functionality is not done until it meets the development team’s definition of done. Transparency builds trust between the team members.
Once the team has agreed on transparency they agree to consistently check on progress (Inspection), and make improvements based on what they have seen (Adaptation). These can be improvements in practices, adopting various communications etc.
In industry the ability to consistently inspect and adapt is very crucial. By doing so, they are improving the product consistently (i.e.. before, during, and after release of a product).
Continuous Inspection and Adaptation is something that is not possible with a Waterfall Model.
SCRUM VALUES
For an individual, team or organization to realize the benefits of scrum, the structural components of scrum framework alone are not sufficient. The components of the framework are the visible, logical system of scrum. Since Scrum is meant to be used by people who have complex, varied beliefs and values that influence their behaviour, it is important to describe their values that make the system work in practice.
The Components of the framework are like the brain of scrum, on the other hand there are 5 Scrum values( Commitment, courage, focus, Openness, and respect) are like the heart of scrum.
- Commitment – In Scrum people personally commit to achieve the shared goals of the scrum team.
- Courage – Scrum team members have courage to do the right thing and work on tough problems.
- Focus – In Scrum, everyone focuses on the work of the sprint and the goals of the Scrum team.
- Openness – The Scrum team and its stakeholders agree to be open about all the work and the challenges with performing the work.
- Respect – Scrum team members respect each other to be capable and independent people.
When these 5 values are followed by the Scrum team, the structures become far more effective at their intended goal of empirical improvement. At the sometime, the structures are designed to encourage the development of the values.
PRODUCT BACKLOG – It is a list of all the features and their acceptance criteria that the business desires for the product.
SPRINT BACKLOG – It is a subset of Product Backlog. Items from this backlog are taken up by the team, and broken down into tasks, and worked on in an iteration called a Sprint.
SPRINT – It is a period of time, generally less than 30 days in length. In this time, the team work on their tasks until they develop a working increment of the product.
There is requirement gathering and specifications updation before the start of a Sprint, then there is Design, Implementation and Testing.
DAILY SCRUM MEETING – Everyday the team meets to inspect on progress and adapt a plan for the day in the Daily Scrum Meeting.
PRODUCT INCREMENT – At the end of the Sprint, a Potentially Shippable increment of the product is delivered. The Business can review the increment in a Sprint review and then release the new features if they so wish. The teams discuss their progress during the Sprint, and Sprint Retrospective so that they can improve all things that needed improvement and retain the ones that are going well.
The Cycle begins again until the Product Owner has nothing more to add to the Product Backlog.
The Scrum Skeleton demonstrates the simplicity and the power of Scrum as a mini factory, churning out shippable features in each Sprint.
SCRUM TEAM ROLES
Scrum simplifies projects down into only 3 roles.
- Scrum Master
- Product Owner
- Development Team
These 3 roles form the Scrum team.
SCRUM MASTER
- Understand the Scrum rules and practices.
- Remove any impediments or blockers to the team in delivering
- Help the team to understand, self organize and work in a Scrum manner.
- He facilitates for the Scrum team whatever it makes sense to do so.
- He’s the go-to person in terms of how the Scrum framework should operate, and this applies to anyone and the organization.
- Helps the product owner to maximize Return On Investment.
- Helps the team to work together and to be as more productive as possible, and deliver a shippable increment of the product on time.
PRODUCT OWNER
- He’s responsible for creating requirements on behalf of the business.
- He prioritizes requirements based on business needs and is responsible for managing the product backlog.
- Responsible for making decisions that maximize the Return On Investment.
- Responsible for making Priority Calls or Trade-offs the Product Value.
DEVELOPMENT TEAM
- Responsible for building a potentially shippable product increment in each Sprint.
- The Development Team are self-Organizing, collaborative, skilled and whatever is needed to develop the project.
- Scrum does not specify all the possible knowledge experts in a Development Team, because the idea is that team members would collaborate to perform tasks outside of their role to deliver the product.
- In a typical technical project you might have developers, graphic designers, and user experience specialists working together in a Sprint to create a product increment.
- One key difference between Scrum and many other frameworks is that the development team are explicitly experts in their field as opposed to controlled resources.
- They look to the Scrum master for coaching, guidance and the removal of impediments.
- They look to the Product Owner for Clear requirements, prioritization, and Trade-off calls.
- Scrum teams are usually small because it helps them to be more cohesive and communicate efficiently. The Optimum team size is 7 (+or-) 2. i.e.. the optimum size is between 5 & 9.
SCRUM TIME-BOXES (EVENTS)
TIME-BOX or EVENT – A period of time dedicated to a specific event in Scrum.
Part of the Scrum Master’s role is to carryout time management very strictly. This means beginning and ending meetings on time, finish Sprints on time. Scrum has a number of time-boxes (Events). It is the Scrum Master’s role to organize and facilitate these events. The Various Events are
- Sprint
- Sprint Planning Meeting
- Daily Scrum or Daily Standup Meeting
- Sprint Review
- Sprint Retrospective
- Release Planning Meeting
SPRINT
It is a period of time, generally less than 4 weeks in length, during which the team builds a shippable increment of the product.
SPRINT PLANNING MEETING
- It is the team meeting to plan the work they intend to do in the upcoming Sprint.
- It is a max 4 hours meeting for a 2 week Sprint.
- There are 2 halves of the meeting: “The What” and “The How”.
In the first half, the Product Owner presents the list of features, that he would like the team to deliver from the product backlog. He explains them and the team asks questions. Eventually they pick the features they believe they can commit to in the Sprint. The team may negotiate with the Product Owner on the features, but they will definitely make a commitment on the things they would deliver at the end of the Sprint.
In the 2nd half, the team breaks the features, that they agreed to deliver in the Sprint, into tasks and estimate them. In this way they design their work and decide how to deliver the product increment.
DAILY SCRUM ( STAND-UP)
This is a Daily meeting lasting no more than 15 minutes.
Each of the Developing Team members answers the following questions asked by the Scrum Master.
- What I did yesterday ?
- What i aim to do today ?
- Do i have any impediments to delivery ?
The Scrum Master takes notes of any impediments and aim to resolve them as quickly as possible. Any issues can be discussed afterwards.
The Sprint backlog, and The Sprint Burn-down should be visible to draw attention to the team’s progress or any impediments.
SPRINT REVIEW
This meeting is held at the end of each Sprint and allows the team to demonstrate the increment of the product to the Product Owner and other Stakeholders (CEO, Customer, Final Product Vendor, Director/Head of The Dept).
The Stakeholders ask questions and make suggestions to the Product Owner. The Product Owner makes notes to adapt the Product backlog if necessary based on the suggestions or the Output from the Demo.
SPRINT RETROSPECTIVE
This is meeting held after the Review and before the next Sprint. One by one each team member answers the questions
- What worked in this Sprint ?
- What could be improved in the next Sprint ?
This is chance for the team to inspect and adapt. It generates continuous improvements. Each of these events has a specific purpose, and these are the only set of events that Scrum defines inorder to deliver a project.
RELEASE PLANNING MEETING
Purpose of this is for the Product Owner to present a subset of features from the backlog and the team to agree what looks feasible to deliver in terms of Scope, or a release date. This, however is not a commitment.
Usually, after 3 to 4 Sprints, the team’s velocity of completing things can be understood. This can be used to calculate, how many features are likely to be completed by the release day, in case of date driven projects, or when the entire Scope is likely to be delivered, in case of Scope driven projects.
SCRUM ARTIFACTS
- Product backlog
- Release Burndown
- Sprint backlog
- Sprint Burndown
- Shippable Product increment and Definition of Done
PRODUCT BACKLOG
It is the list of all the features that the Product Owner would like to see in the finished product. This list constantly evolves and changes over time. Product backlog is a ‘Constantly evolving Artifact’, and it answers the question – “What is most important to build next ?”
The Product Owner maintains the backlog and works with the business stakeholders to form requirements. He also works with the team to get suggestions, Technical inputs, and estimates. Since the Product Backlog contains features that are prior to the life time of the whole product as opposed to the release, a number of features that the product owner would like to release is referred to as a Release Backlog.
RELEASE BURNDOWN
The Release Burndown is a common method of monitoring progress towards the release of a product. It shows the number of story points and Sprints remaining to your launch. Simply put, the Release Burndown makes it easy to see if a project is on track. If the project is on track, then the line will be on or very close to its diagonal guideline.
SPRINT BACKLOG
It is the set of items that the development team will work on in a Sprint to deliver an increment. It is the selection from product backlog, initially picked by the product owner, but finally committed to by the development team.
It consists of features, tasks and their estimates.
SPRINT BURNDOWN
Like the Release Burndown, The Sprint Burndown helps the Scrum team monitor progress in a Sprint.
Number of days on X-axis, and number of tasks remaining on the Y-axis.
SHIPPABLE PRODUCT INCREMENT & Definition of Done
This is a piece of functionality delivered by the team at the end of each Sprint. It should be potentially shippable and meet the team’s definition of done agreed at the start of the project.
In Scrum, the development team works to deliver a new increment of the final product every sprint. Each increment is a New, Updated, and Usable version of the product, so the product owner may choose to immediately release it. A Product increment is a tangible output of each and every sprint.
The increment can be considered “DONE”, if it can be released without any additional work. Each increment is additive to all prior increments, and is thoroughly tested ensuring all increments work together.
In order to assess When work is complete on a product backlog item or an increment, the Scrum team creates a shared “Definition of Done”. This definition provides transparency about the level of quality that is considered sufficient to release an increment. The “Definition of Done”, guides the development team in knowing how many product backlog items to select during Sprint planning. When multiple teams work on the same system or product release, they collaborate to create a shared minimum definition of “Done”, to which all teams will adhere.