Understanding Scrum

Understanding Scrum

Hello friends, It’s the end of May 2018. after a long gap, I am writing once again, I was pretty much occupied for the last few weeks with multiple areas.

This article is about one of the most important and commonly used frameworks of agile. As we earlier have covered many other articles on Scrum ceremonies, Roles artefacts, etc. Here we will be connecting all those details learning in a framework called Scrum. We will understand here the agile development life cycle using the Scrum framework. Before I start let’s quickly talk about Why Scrum or even why agile, and then will jump into one of its frameworks called Scrum

Why Agile? 

Before you jump into Scrum, let’s just recall the traditional way of software development and the disadvantages with that, and how Agile Mindset resolves those gaps and adds value.

Let’s quickly talk about what is a waterfall

With Waterfall Model, it takes 9 months to 1 year even more to complete a software development, which includes

1. Requirement Gathering
2. Analysis And Planning
3. Design
4. Development
5. Testing
6. UAT
7. Deployment.

These are the typical phases of the waterfall, Refer to the image to get a pictorial representation of the model at a high level. The typical documents this model generates are like

1. Requirement Specification
2. Project Specification
3. Design Specification
4. System Specification
5. Test Cases
6. Tractability Matrix, etc

Using this model the return of investment started visibly by end of all the phases (1 year or so).

With Waterfall Model

Transitioning to Agile (Mainly Scrum)

We have already learned so far about the considerations, limitations, and disadvantages of the Waterfall model in this dynamic marketplace. Now let’s see how development with an Agile Mindset overcomes those challenges. I will not cover the history of Agile, and how it is evolved. But will talk about little difference between Waterfall and Agile, In this article, I will highlight primarily the Scrum framework. The diagram demonstrates the difference between Agile and Waterfall with the three components Cost, Schedule, Scope In waterfall we talk about the Scope is fixed, what varies is Cost and Schedule. That means we need to calculate how much time and cost it will take to deliver this scope. Where In Agile the Scope is variable and cost and Schedule are fixed, where we can plan or calculate how many scopes we can deliver with this Cost and Schedule.

Let us develop a cake and assume one complete cake is our complete product. with the traditional way of development, we will be able to complete the whole cake in one year. Assume each layer of the cake is one phase of development. refer to the image below to get the explanation better.

To develop the full cake may take a year (hypothetically), by the time the cake is developed, Market demand may change to a different flavour of cake, The return of an investment will be delayed for a year, and that too with uncertainty and risks.  So the Industry has adopted another way to develop and deliver to counter this uncertainty and risks. And Agile way of working is the mindset to overcome the risks and uncertainty. Scrum is one framework that follows the Values and principles of agile.

Let’s see the same cake development with Scrum.

Within Scrum The product Owner, for this example The Bakery Owner has a detailed vision of what to develop, but to get the return of investment faster, he/she decided to create one slice of cake first. This is called vertical slicing. where we will create one vertical slice instead of the whole product. upon completion of each vertical slice can be put into the market and ready to sell. Each vertical slice will take less time, and will have fewer risks and uncertainty.

Refer to the image below, to understand the concept better.

Now assume each slice development is a Sprint the Timebox or iteration of the scrum, which we will explain in detail later. each sprint has its own phase of requirement gathering or analysis, design, development, testing, etc. After completion of each sprint, we will be able to make some potential sell-able or ship-able products. That is the essence of working with the Scrum framework. Product Increment with Iterative and incremental way. when it comes to software development we need to follow some principles and values. and also we need to think about releases Goals, Sprint Goals, etc. The diagram below explains a scrum way of development to demonstrate product increment on iterative time boxes.

Our primary focus of this article is to understand Scrum, will not talk about Agile much, there are some important Agile Values that Scrum also inherits along with Scrum Values. The Agile Values are as below, which follow all frameworks under agile.

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

for details of Agile Values and principal refer to the Agile Manifesto

What is Scrum 

Scrum is a framework for delivering and sustaining complex products, which collaboratively and collectively resolve complex solutions. Which delivers products in an incremental way to generate a faster return on investment. Scrum is not a Process or Methodology. It’s Simple. Scrum implements the imperial model by Transparency, Inspection, and Adapt. Scrum promotes Self-organization and team collaboration. Nowadays the Industry is going towards Scaling Agile by adopting Scaled Agile Frameworks like SAFe, Spotify, Nexus, DAD, LeSS, etc. However, Scrum is still essential at the team level. Even if we are working on any Scaled agile framework, Scrum is required at the execution level. Lets quickly have a quick look at the Scrum life cycle, and then we will talk about each node of the life cycle

Scrum Life Cycle

We will distribute the Lifecycle in two parts one is Ongoing activity and another is Iterative activity.

Ongoing Activities There are some ongoing activities, which means not depend upon sprints or Iteration. like Creation of Product Backlog Items (mainly stories), Prioritizing the product backlog Item, Backlog grooming, Define the definition of ready and done. These activities are needed to be continued, better to be in cadence.

Iterative Activities  These are activities a scrum team executes within a sprint and the outcome of those activities consumed or utilized within the sprint. as Sprint starts with Capacity Planning, Sprint Planning, continue Daily stand-up for every day, sprint end with Retrospective and Review. within a sprint, the Team has a Goal to deliver and a maintain a Scrum Board to have a visual representation of the progress, roadblocks, etc. The team commits to a set of product backlog items during sprint Planning based on their capacity. Maintain a burndown chart to check the remaining amount of work for the sprint every day.

To understand the primary areas of the scrum, let’s talk about these 5 points.

Requirement / Artifacts

The Product Owner has the vision of the product and creates that requirement in the product backlog in form of User Stories.

The Scrum team commits the prioritized user stories at the beginning of each sprint based on the capacity and creates a Sprint backlog. The sprint backlog items are the set of requirements, that the development team will work on for the specific sprint/iteration to full fill the goal of the sprint and add value to the Product Owners vision by making a potentially shippable product increment. The burn-down chart is another artifact of Scrum, which many people believe to have a Definition of Ready and Done is also an artifact of Scrum. Team / People The primary roles in Scrum are Product Owner, Scrum Master, and the execution team Process The process here is the Ceremonies the team will follow, like Sprint Planning, Backlog Grooming, Retrospective, Sprint Review, etc. Tools The Tool a Scrum team can use to manage their Agile life-cycle management, like Jira, Rally, Version One, Excel, etc. Engineering Practice The Engineering practice the construction team will use to develop like XP, TDD, BDD, etc

Let’s talk about the above topics in detail.

Requirement / Artifacts

So each Item inside the product Backlog is also called PBI (Product Backlog Item). and to summarize we can say a Product backlog is a list of the prioritized work item.

To explain the characteristics of a Good Product Backlog there is a popular Acronym called DEEP Roman Pichler, author of “Agile Product Management with Scrum: Creating Products That Customers Love“ and I use the acronym DEEP to summarize key attributes of a good

• Detailed Appropriately. The Product Backlog Item Needs to have enough details inappropriate way to understand what exactly the ask is and the expected functionality in detail, with all validations and logic.
• Estimated. The Product Backlog Items is not just only the requirement, it should also provide enough data to Plan for releases and milestones. it’s very important to have an estimated backlog to plan effectively
• Emergent. The creation of a backlog item is not a one-time activity, It’s a dynamic content log. It changes over time. With time and knowledge, the Product Backlog Item can be added, removed, re-prioritized, or modified.
• Prioritized. The product backlog should be ordered with the most valuable items at the top and the least valuable at the bottom of the list. By always working on the most valuable item first, the team will be able to maximize the value of the product increment.

https://youtube.com/watch?v=R62Iu_4zcpU%3Ffeature%3Doembedhttps%3A

Sprint Backlog

Sprint Backlog is a subset of the Product Backlog Items (PBIs) selected for a specific sprint. As we know each sprint has a time box, At the beginning of a sprint the scrum team selects a set of PBIs which meet the Definition of ready and in top priority. Keeping in mind the capacity of the Scrum team. A Sprint Backlog lasts for the duration of the sprint, it forms on the first day of the sprint and dissolves on the last day of the sprint. the Completed PBIs go back to the Product Backlog with a “Closed” State and Incomplete PBIs go back to the Product Backlog as an “Open” state. The team forms a new Sprint Backlog for the next sprint during the Sprint Planning meeting. To understand the formation of sprint back, refer to the image below. It explains the formation of two sprint backlogs for Sprint 1 and Sprint 2

The Items of sprint backlog or product backlog can be

• User Story
• Technical Spikes
• Bugs

But in Sprint Backlog, You may have two more items that are called Sub-Tasks or Sprint Defects Each Backlog Item have a workflow path to travel, starting from New to Done. for an example, a workflow for a User Story can beNew – Committed – DevInProgres – TestInProgress – Review – Done
or
New – InProgerss – Done
or
New – Analysis – Construction – Review – Done For Sub Task you can simply have To-Do — In Progress — Done
or the way you think best fits your need We will learn more about sprint backlog in the section on sprint Planning

More about Burndown Charthttps://www.youtube.com/embed/Lr45NwjFVdw?feature=oembed

Other Artifacts (DOR & DOD)

DOR or Definition of ready and DOD Definition of Done is the checklists defined by the scrum team before the first sprint, sometime during Sprint 0. These two checklists are useful to avoid any kind of conflicts and give a direction and standard to work on. DOR: Helps the team to decide and measure for any particular PBIs is ready for the sprint. that means if the PBIs meets all the checkpoint  of the DOR, they it can be taken for the sprint for execution. Scrum Master and the team validates the PBI from the DOR checklist before committing to a sprint. DOD: Similarly any PBIs that are currently under active sprint, should only be treated as done if they meet the definition of done. Product Owner who is responsible to accept the PBI completion, refer to this Checklist to mark a story or any PBI as done. There is noticed negative aspect of this DOR and DOD, Many teams misuse the presence of DOR and DOD and become very strict to Commitment and Acceptance, which ultimately decreases the Incremental flow. Please Inspect the current situation of your development piece, and update the DOD and DOR if it is required. Also, don’t change the DOR / DOD very frequently, then it will lose its main purpose.

These are the example of DOR and DOD to get a reference. Please define your own DOR/DOD as per the Need and nature of work.

From the image below try to understand at what workflow stage these DOR and DOD can be refereed

People (Scrum Roles) 

There are three distinct roles in Scrum

1. Product Owner
   Holds the vision for the product
2. Scrum Master
   Helps the team best use Scrum to build the product
3. Development Team
   Builds the product

There is some instance where you may get a chance to another team called cross-function team. We will learn high-level about these roles and responsibilities. In detail, I will write an in-depth article on each scrum’s Role and Responsibility sometime later. Let’s See who is Product Owner and what is his primary role

Product Owner

To develop any products, we need Requirement || Execution || Delivery. The Product Owner is responsible for Gathering requirements from Business Owner or stakeholders or sometimes from his/her own expectation. So from people, prospective Product Owner is the single source of requirements. Product Owner who breaks the large requirement into small functionality in form of user stories. PO adds the user stories into a place called Product Backlog. This Product Backlog can be anything like an Excel list of rows, each row represents an Independent small fully functional requirement, or any ALM tools like Jira, CA-Agile Central (Rally), TFS, Version one, etc.

Apart from creating user stories, PO is also responsible for

1. Prioritizing the list of user stories in Product Backlog.
2. Make the development team understand the requirement and expectations of each user story, in priority.
3. Participate in major scrum ceremonies

The Product Owner has the authority to accept or reject the story completion, keeping DOD as the rule book. He/she continuously works together with the team during each sprint and provides feedback by accepting or rejecting user stories when the development team marks them as developed and tested. Product Owner and only Product Owner has the authority to terminate any active sprint if he/she realizes the committed user stories will not add any value increment to the specific situation. Product Owners become a bridge between the Scrum team and Business. PO helps the team to visualize the vision of the Business. The Product Owner also invites stakeholders during sprint review to demonstrate the upcoming Product Increment and also capture feedback from Business sponsors or stakeholders to make the product Backlog up-to-date and emergent. In many Instances, the Product Owner seems to be a little occupied with other engagement, on those cases a Business analyst seems to have compensated for the gap and shadowed the product owner for a few responsibilities like Creating and Maturing User Stories, making team understand the requirement, etc. The authority of prioritizing, Accepting, rejecting story completion, and Terminating Sprint are still being with PO only.

It’s always suggested that the Product Owner should be from the Business side to maximize the benefit of working together.

Scrum Master

The role of a scrum master is to protect the Agile process, maintain the discipline by ensuring the team follows the best practice of agile, and maximize the value increment. Scrum Master is a Servant Leader is a facilitator, is a local coach to the team. Scrum Master Prompts and Supports Scrum. Scrum Master helps everyone to understand Scrum theory, Practice, Rules, and Values. and maximize the value outcome. Scrum Master is also known as the process owner. Scrum Master Servers to all other Roles and cross-function team as well. The high-level responsibilities of this role include:

• Establish the Scrum Framework
• Enable Transparency, Inspection, and Adaptability
• Resolving Impediments
• Establishing an environment of Agile Development
• Protecting the team from outside interruptions and distractions.
• Represent a holistic approach

Scrum Master Organize, facilitates, and participates in all agile ceremonies, do reports wherever required, Maintains data for metrics and Trend analysis, Trains people to understand the Scrum framework and its process and its value, Coach teams to get the benefit of the scrum to maximize the value increment. Scrum Master is not a Manager, Scrum Master doesn’t have authority to hire or fire. Scrum Master can not take a secession of Skill allocation, or task allocation, Scrum Master doesn’t participate in estimation, however, he facilitates the estimation process.

Development Team, The development team is the group of the technical team responsible for the construction of the product by coding, designing, testing, etc. This group of people are having a combination of technical skills, and are capable of converting the vision of product owners into useable functionality, which becomes contributes to the final product. Remember the development team should skill set of people which together can complete the construction of all committed user stories, from beginning to end (Analysis, Design, Development, Testing, Review) within one sprint. That means it should not have Two or more teams for performing a different set of skill sets. having one team for design and another for development and another for testing is wrong and a bad team structure. It’s a good practice to have the development team structure fixed which means the team membranes should be part of the same team for as many sprints as possible. Changing the team structure very frequently is not good practice, which breaks the rhythm, and decreases productivity. The development team takes to participate in all Scrum ceremonies with defined responsibility, which will cover details of roles and responsibilities in some other articles.

Scrum Ceremonies 

Scrum Framework is designed with a couple of collaboration meetings to encourage working together.  This collaboration is a kind of meeting where the entire team comes together physically or digitally to fulfill some purpose. Each of these meetings is called a Ceremony in Scrum. and each ceremony has a purpose. Will learn more about these ceremonies in detail here. The list of ceremonies is as below.

1. Capacity & Sprint Planning
2. Backlog Refinement / Grooming
3. Prioritization
4. Daily Scrum Call
5. Sprint Review
6. Sprint Retrospective Let’s try to understand these ceremonies in detail.

Capacity Planning Planning the Capacity means estimating and calculating the capacity of the Agile team. There are two widely used capacity measurement units

1. Story PointsThis is a Simple way to calculate the velocity (Average of last 6 to 10 Sprint’s Accepted Story Points). and target the upcoming Sprint to commit the User Story that closely matches the velocity. I Personally recommend the other way of doing the capacity planning by calculating it by Hours. 2. Hours I personally recommend Capacity Planning by Hours. I will explain only this way of Capacity Planning in this Article. It gives better visibility and accuracy.  And many other benefits that we will discuss later in this article. Here we Calculate the available bandwidth of the Agile Team (except PO & SM).  By calculating their available hours for the upcoming Sprint. Will discuss in detail how to calculate it, and what factors we should consider in this article.

Learn more and in detail about Capacity Planning

Sprint Planning

In Scrum, we have multiple time boxes called Sprints or iterations. In each Sprint bunch of functionalities in the form of stories are implemented to make incremental enhancements to the product under development. The Sprint Planning meeting is the kickoff meeting for each Sprint. This meeting helps set the context of the sprint by scoping the product owner goals for this sprint. It also prescribes the priority for the stories, based on available bandwidth/capacity to meet the goal and deliver incremental value to the product.

Learn More in detail about Sprint Planning from the below article and Video.

Backlog Prioritization

Product Backlog prioritization is one of the most important exercises in agile software development.  Any project is successful if the stakeholders or clients or business gets the most valued functionality at the earliest. And that is possible by effectively and consistently prioritizing the requirements (users’ stories). Backlog prioritization is required to organize the product backlog items (user story/Defects/Spike etc) to make the sequence of its development and deployment. This Sequence is followed by the scrum team to choose product backlog items during grooming or sprint planning. The influencing factors for prioritizing product backlog items are

1. Customer Satisfaction
2. Business Value
3. Complexity
4. Risk & Opportunity
5. Cost

Backlog Refinement / Backlog Grooming 

Product Backlog Grooming, It’s a most useful ceremony for the scrum teams to define the stories, by maturing up its content, clarifying doubts and questions, size relatively, And making the story ready to start working on it any time. Most of the team/organizations get the benefits of grooming by conducting this ceremony religiously, however, few teams/organizations are still in a debate about using it, or not giving enough importance to this ceremony. A team can achieve a well-maintained healthy product backlog by conducting this ceremony effectively and regularly. This ceremony is also known as Product Backlog Refinement or Product Backlog Management

In this article and video tutorial we will learn every detail of Product backlog grooming, Team members’ roles in Grooming, what are the benefits, Insights, and Actions items in the Product backlog grooming, and How to Measure the effectiveness of Grooming, What exactly we do in Grooming, etc?

Learn More in detail about Backlog Refinement / Backlog Grooming from the below article and Video.

Daily Scrum 

Daily Scrum meeting is also called can Scrum call or Standup meeting. This meeting owned by the Scrum team happens mostly during the beginning of every day. Should last for a max of 15 minutes. Where the development team members discuss the work they have done and make the strategy work for the day. They highlight the impediments if any. This meeting ideally takes place at the same time and same place. For a co-located team all the participants stand in front of the physical scrum board (ideally the task board) and talk story by story or person by person, Scrum Master facilitates and takes ownership of any impediments or provides updates with the presence of PO. Though its majorly known as the daily scrum call, both Scrum and Kanban teams ideally conduct this agile ceremony. We will discuss in detail the daily scrum call on each and every part of it in this article.

Learn More in detail about Daily Scrum from the below article and Video.

Sprint Review Meeting

Sprint Review Meeting also known as Sprint Demonstration usually held on the last day of the sprint to demonstrate the accomplishment from the specific sprint commitment. Product Owner from many Agile practices, also review the completed story and mark them as Done or Not Done based on “Definition of Done”. This Meeting is the realization phase of each sprint cycle. This is an Informal meeting, No need to prepare Powerpoint slides or any presentation. This meeting also supports the Agile framework as Empirical Model, by Inspect and Adapt. Inspecting the Product Increment and Adapting the Product Backlog. There are no defined rules for this meeting, But the meeting has to happen at end of every sprint to have the green signal from the Product Owner or stakeholder for the potentially ship able increment, which was constructed during the sprint.

Learn More and in details about Sprint Review Meeting from the below article and Video

Sprint Retrospective Meeting

Sprint Retrospective is one of the important ceremonies of your sprint cycle, It’s usually very common in the Scrum framework, many teams also conduct this ceremony for their Kanban practice on a regular interval.

Generally, this meeting takes place after the sprint review meeting and before the sprint planning of the next sprint. If you want to conduct your meeting for your kanban cycle, you can define an interval like every 15 days to schedule it. This meeting enables the feedback loop to achieve continuous improvement. No matter how mature your team is, opportunities for improvement are always there. This meeting gives the freedom to all members of your team to speak about what they feel can be improved, or what they feel can be stopped. This meeting also enables the empirical model by inspecting the process from transparent input and adapting opportunities for improvement. The main difference between a sprint review and a retrospective is, Sprint review talks about the achievement, upcoming works for the functional increments, and more about the product. where retrospective highlights more about the process like. “Resolution of cross-functional dependencies” can be improved, “On-time joining on daily stand-up can be improved”. etc We will talk about details about, How we can conduct a Retrospective, Different ways of Doing a Retrospective, Tools you can use to do your retrospective, and how to capture and work on the action item of the retrospective.

Learn More in detail about Sprint retrospective Meetings from the below article and Video.

Other Key Areas of Scrum

There are other pillars of the scrum that are very important to understand

1. Estimation
2. Requirements
3. Visual Boards (Scrum Boards)

Let’s try to understand these ceremonies in detail.

Scrum Estimation We definitely need estimation to plan our software development, in agile we do estimation in a little different way than traditional effort estimation, it’s easy, interesting, and yes effective too. In Agile Estimation, we can estimate its different hierarchy items ( read about story hierarchy ), in this article we are focusing on estimating user stories and their tasks. Traditionally we use to estimate efforts to develop functionality, wherein in agile we estimate Business values or Complexity of a user story level. And estimate efforts at the Task level. The unit of estimating a user story for its value or complexity is story points, and the unit of estimating a task for its effort is Hours. We usually relate T-Shirt sizing with Story sizing to mark the relative difference between user story sizes, e.g., Extra Small, Small, Medium, Large, Extra Large, etc, We will discuss story points in detail, later in this article. The below diagram will help you understand story level estimation and Task level estimation.

Learn More in detail about Agile Estimation from the below article and Video.

Scrum Board

A Scrum Board is a physical or virtual space that represents the scope of the current sprint and its status. The current scopes are broken down into executable tasks during sprint planning. A Scrum board mostly has the stories and their associated tasks. These boards are often called task boards as well. Its also called Sprint Board or Task Board Physical Scrum Board Mostly co-located Scrum Teams, keep all the committed product backlog items along with the tasks for a sprint, on a board, or even on a wall. Any space that can be used as a flat vertical space, and accessible to the development team Virtual Scrum Board or Digital Scrum Board A Virtual Scrum Board or Taskboard is the same as your physical board. But it’s programmatically generated and rendered on your screen. It has the capability to share on multiple user screens with real-time updates of other members’ changes. Typically a distributed scrum team uses a virtual scrum board, as the single physical board is not accessible to everyone. Modern days ALM Tools like, Rally, Jira, Version One, TFS, etc provides one or many screens with extensive customization facility to prepare the virtual Scrum Board.

Learn More and in detail about Scrum Board from the below article and Video.

Agile Requirements

In Agile Software development, the execution level requirement or functionality is termed a user story. A user story can be of one or more sentences. The requirement (details contents) in the user story needs to be sufficient enough so that

1. A developer can start and finish his development
2. A tester and test the developed code to check if it is meeting the required functionality
3. The product owner/ BA / Stakeholder can verify the desired functionality to accept the story completion.

Each story has been to fulfill a requirement with a very specific goal or benefit, it’s always advisable to break any store into smaller stories if it has more than one goal Requirement of a story has to be of complete functionality, which means upon completion of development, testing, and acceptance, the code should be deployable, or park for future release. In another word, each user story should be potentially shippable. The size of a user story is measured in story points (Refer to our section Estimation Techniques), to provide a business value or complexity.

Learn More in detail about User Stories from the below article and Video.

SCRUM REPORTING

Though Scrum is for continuous Development and Delivery, There are some reports we can create sprint over the sprint, which we will cover under some different articles. here is a list of some reports you can think about.

1. Grooming Updates
2. Sprint Planning Summary
3. Midweek Progress Summary
4. Sprint closure summary
5. Retrospective Action Item

SCRUM METRICS