Agile methodology has taken the software development and testing world by storm over the past few years. According to the latest report, 97% of all respondent organisations practice agile methods to facilitate the development process.

Scrum is the most popular agile framework. Almost every software development team in the world is using various aspects of the Scrum framework in some shape or form.

Piece of cake! Isn’t it? Now, let’s look at each artefact, role and ceremony in more detail:

Product backlog is an ordered list of various work item that needs to be done. These work items are called Product Backlog Items (PBI). Items at the top of the backlog have higher priorities and items at the bottom of the backlog have lower priority. No two items have the same priority. Every item has more priority than the item below it and less priority than the item above it. The product backlog is not a queue and can be constantly reprioritized and changed by the product owner.

Items at the top of the backlog are more refined and are more ready for the team to start working on and items lower in the backlog are larger and more abstract. PBIs can be various things including but not limited to requirements (user stories), bugs, Spikes and research tasks, tech debt, and so forth.

Product Owner

Product owner is the person ultimately responsible for the product. They steer the development by prioritising the work. Product owner has content authority of the user stories. Based on the input from the stakeholders and the product/team vision, the product owner makes decisions on the work that needs to be done. Product owner is responsible for defining the “why” and the “what” but not the “how”.

Product owner not the boss of the team, they are just another team member like everyone else. They are however the boss of the product backlog. They own the backlog. They decide what gets built next by prioritising the backlog.

The most important attributes of product owner are:

• Domain expert (understands the product really well)
• Available (collaborates with the team)
• Stakeholder manager (ability to say no to multiple directions)
• Empowered (ability to make important decisions independently)

The Development Team

The development team or the developers are the people who build the product. A developer in the context of Scrum does not mean a computer programmer. It means anyone who participates in the development of the product. For example, this may include Programmers, Testers, UX designers, Business Analysts, Tech Writers, Release Leads, Architects, etc. Basically, everyone on the team except the Scrum Master and the Product Owner are developers.

Developers are responsible for defining the “how”, but they can also contribute and help product owner on the “what” and the “why”. The development team needs to remain stable over long periods of time. We can’t add/remove developers to the team at will.

• The best analogy to describe the development team is the Guardians of the Galaxy.
• They are NOT superheroes. They don’t have super powers. Except for maybe Groot.
• They have T-shaped skills. Highly skilled at one thing but also a little skilled at a few other things
• They may have their differences but they collaborate really well.
• They cover for each other.
• They may look selfish at first but they are prepared to die for each other.
• They all have their quirks, but do the right thing at the end of the day.
• And most importantly they do whatever it takes, whatever it takes, to get the job done.

Scrum Master

The Scrum Master is quite literally the master of Scrum. When we say someone is the Scrum Master, does it mean everyone else are the Scrum Slaves? No! The Scrum Master is more of a “Servant” rather than a “Master”. They need to serve the team and make sure the team gets whatever they need to work at optimum performance.

“Master” here refers to mastery. It means the Scrum Master is highly skilled at Scrum. They are the Scrum Coach for the team, the team facilitator and the remover of impediments.

Scrum Masters are leaders, but lead without having authority, just like Nelson Mandela, Mahatma Gandhi, and many other servant leaders in history. They persuade rather than using authority and lead rather than manage. The Scrum Master is not the boss and the team doesn’t report to the Scrum Master.

The best analogy for the Scrum Masters are Jedi Knights from the Star Wars Saga:

• The Scrum Master is the glue for the team.
• He has great relationships with everyone.
• He is a facilitator.
• Makes sure the processes that the team agree upon are followed.
• He is the impediment bulldozer.He uses a light-sabre to open up the path for storm developers (storm troopers) to move forward into enemy territory.
• He is diplomatic but not political. Witty and clever but righteous.
• He travels across the galaxy to facilitate and remove impediments.
• And most importantly he uses “the force” to sense impediments before they are even emerged

Sprint Planning

In the Sprint Planning meeting, the team plans for the sprint. The sprint planning is time boxed maximum of 4 hours for 2 week sprints. This meeting happens at the beginning of the sprint. At this sprint we talk about how much work can be done this sprint and how the chosen work will get done.

During this meeting the team starts picking up PBIs from the top of the product backlog. They discuss each item and clarify questions with the product owner. They estimate the PBI if not already estimated and start thinking about implementation on a very high level and not too much in technical details. Then they will move to the next PBI from the product backlog. The team repeats this until they feel they are at capacity.

The work that the team plans to deliver this sprint is called the Sprint backlog. Then based on the work that the team has picked up in the sprint backlog, they construct a Sprint goal.

Finally the team commits to deliver the sprint backlog by the end of the sprint. And the product owner commits not to change anything in the sprint backlog during the sprint. If the product owner makes any changes it will void the team’s commitment.

Sprint Backlog

As mentioned above the sprint backlog is the plan that the team comes up with for the sprint. The sprint backlog is owned by the developers. The order of items in the sprint backlog is decided by the dev team not the product owner (unlike the product backlog). The product owner cannot make any changes to the sprint backlog. If the product owner needs to absolutely make changes to the sprint backlog in certain circumstances, they will void the commitment/forecast of the team to deliver what they said they will in the sprint.

Backlog Refinement

Backlog refinement (A.k.A. Backlog Grooming) is the process of refining and preparing the PBIs for the upcoming sprints. Typically there is a backlog refinement meeting to talk about and estimate the PBIs prior to the sprint planning. The better we prepare and refine the PBIs before the planning meeting the shorter and easier the planning meeting becomes.

Sprint

Sprint is a short timebox where the team refines, builds, and tests PBIs. At the end of the sprint a potentially shippable product increment must be produced. Typically sprints are 2 weeks but it can be really any length, I have seen 4 week sprints, 3 week sprints, 2 week sprints, 1 week sprints and even 2.5 day sprints. It is a decision that needs to be made according to the context.

Not that once we set the sprint length we don’t want to change it and we want to keep the cadence.Every sprint the team iterates and goes through the same process again, incrementally delivering potentially shippable product increments.

Daily Scrum

Daily Scrum or Daily Standup is a short meeting that happens every day while standing up next to the team kanban task board. The Daily stand-up is timeboxed to a maximum of 15 minutes but ideally you want to finish your standup in 5 minutes.

The daily Scrum is not a problem solving venue. Neither is a status update. The daily Scrum is a venue primarily for identifying impediments. It is also a venue for confirming if we are still on track with achieving the sprint goals.

There are 3 questions that everyone needs to answer in the daily stand up:

• What did I do yesterday?
• What will I do today?
• Do I have any impediments?

The daily Scrum is followed by a meet after in case some people need to discuss anything specific or get into more detailed conversation

Each team will have a definition of Done (DOD). This is to align what done means. The team needs to write the DoD, print it, and put it on their wall. The DoD defines what a potentially shippable product increment means. Ultimately Done in Scrum means released to customers. However in most cases it is not practical to release to customers within each sprint. For a start, most teams do not have a continuous delivery pipeline. Even if they did have it, deployed to production does not necessarily mean released to customers. This is because typically there are other activities such as documentation, customer communication, marketing, compliance and many other activities that need to be done before new features are released to customers.

The “potentially shippable” in potentially shippable product increment is referring to this. That shipping the product is a business decision. The team needs to make sure it is potentially shippable and the business makes the call to ship it or not.

The sprint review is the event that the team (including the product owner) demo the work they have done during this sprint to a wider stakeholder group. The primary purpose of sprint review is to inspect and adapt the product and get feedback from the wider stakeholder group.

Now let’s be quite clear. Sprint review is not just a “showcase”. Calling sprint review a showcase trivialises the review to just a demo rather than a collaborative session where stakeholders provide feedback. It is a review of the potentially shippable product increment not a showcase of what we did in the sprint.

This is the event where the team focuses on themselves and the process. They inspect and adapt the previous sprint. During the retrospective the team looks at the sprint and brainstorms on what to keep and what to change. Every retro needs to have 1-3 actions. The teams need to come up with experiments and implement them. Then review their experiments in future retro. We want to inspect and adapt in short small cycles that is why we do a retro every sprint.

Scrum is based on empirical process control theory. Empiricism is what the scientific method is based on. It means in scrum every opinion remains a hypothesis until it is validated.

In order to have empirical process control we need to have transparency, inspection and adaptation. It means we come up with hypotheses, we keep a transparent environment, we inspect, and based on our learning, we adapt.

Scrum is designed in a way to maximise transparency, inspection, and adaption. Ken Schwaber, one of the original creators of Scrum, puts it this way: Scrum is like your mother-in-law, it points out all your faults.