Skip to main content

Scrum is an Agile framework for helping teams work together to consistently deliver incremental value.

Scrum was originally designed for product development teams. However we have worked with and transformed, Start-ups, Finance Teams, Quant Teams, Marketing Teams, Sales Teams and Audit Teams through the application of Scrum. These teams frequently realize increased productivity, creativity, delivery cadence and overall reported happiness which is why they have sent their team on scrum master courses in the UK.

Scrum is no longer just for software teams but for any team that regularly delivers value.

Scrum consists of 5 events, 3 roles and 3 artefacts.

What is the Scrum Framework?

There are many differences between Agile and the Scrum framework. A framework consists of the essential elements needed to support a structure. So, Scrum as an agile framework consists of minimum indispensable components (5 events, 3 roles and 3 artefacts). Scrum does not offer a fully comprehensive manual for every possible combination of project situation. Instead, Scrum offers a process that allows teams to adapt their approach to one that consistently works for the teams situation.

Because Scrum is a lightweight framework offering only essentials, there is an expectation that a Scrum teams’ practices and approaches will enhance as the team learns what does and does not work during its lifetime of consistent delivery.

Scrum is built on the three pillars of Transparency, Inspection and Adaptation

Transparency means two things.

1. Anyone doing the work or involved in the work can see what is happening.

2. Everyone understands what is being seen in the same way

For example, development teams usually do their daily meetings around a Task Board or Scrum Board. This board illustrates the Development teams progress and what (if anything) is threatening their delivery. The board makes the teams’ work transparent to everyone in the team

Inspection means that teams frequently check current progress against expected progress and note the gap.

Adaptation means that if there is a gap between expected and current outcomes, the Scrum Team changes its processes to close the gap.

Scrum encourages consistent learning through experience.

Scrum is based on empirical process control theory which is in essence, learning by doing.

Empiricism is the belief that knowledge comes only or primarily from experience. Scrum expects the use of the team’s experience to regularly enhance their processes to enable consistent delivery.

The Scrum framework creates the environment for teams to become conscious of what is working and what is not. The team is expected to use their collective experience to develop and mature their processes to do more things that work and less of what doesn’t.

Scrum is all about consistent value delivery

One of the core tenants and repeating themes of Scrum is consistent value delivery.

Scrum mandates that the whole team is responsible for a potential release at the end of each Sprint (a Sprint is the longest timed event – more on this later).

This means that whatever the team needs to do to ensure that the deliverable is usable by a customer needs to be complete. For a typical software team this usually means, code complete, unit tests complete, integration tests done, any documentation written, integration testing and front-end testing done!

Scrum consists of five timed events, three roles and three artifacts.

Scrum consists of five events that facilitate close collaboration – the events are simply

  • The Sprint 1 month or less (which contains…)
  • Sprint Planning
  • The Daily Scrum
  • Sprint Review
  • Retrospective

The Three Scrum Roles

  • Scrum Master – trains, mentors and coaches Scrum Teams and the organisation in good Scrum
  • Product Owner – owns the Product Vision – what must be done
  • Development Team member – delivers the Product Vision

The Scrum Artefacts are

  • Product Backlog
  • Sprint Backlog
  • The deliverable

What is a Sprint?

A scrum Sprint is a container event which is a maximum of one month long but most teams run two-week Sprints.

A good way to think of a Sprint is like a mini-project. A project ends with everything done and working, and happy stakeholders. So too with a Sprint. The idea is that everything the team had hoped to do to deliver the business goal is done, and like most projects the Sprint ends with a Sprint Review of what was delivered and a lesson’s learned meeting known as the Sprint Retrospective.

The purpose of a Sprint is for the Scrum team to deliver a potentially releasable increment.

Unlike the other 4 events, a Sprint cannot be shortened. Sprints remain generally consistent throughout a delivery effort. Scrum teams usually maintain a constant Sprint duration. so if a Sprint is set at 2 weeks, they usually remain at 2 weeks throughout the project.

What is Sprint Planning?

On the first day of a Sprint, the Scrum team gets together and plans the work for the Sprint to achieve the business goals that the Product Owner believes offer the most value. The Product Owner is expected to understand what delivers the highest business value whilst considering the risks that affect the potential deliverable. Such risks can be things like multiple-dependencies, issues, team availability and assumptions.

The important thing to note here is that the Scrum TEAM plan together and agree on a Sprint Backlog that achieves the goal. A Sprint Backlog is a list of the work the Development team believe they can accomplish during the Sprint to achieve the goal.

Sprint planning is a collaborative event, the whole team inputs and works together to generate a good plan that achieves the goal. This means that Sprint planning is attended by the Product Owner, the Scrum Master and the Development team.

Planning like this reduces risk as the whole team builds a plan that they all buy into and will have assessed together for achievability. 7-10 minds planning together usually generate a better plan versus just one person trying to think of all the work plus the risks, issues, assumptions etc that might derail the plan.

Notice how this is different from most waterfall project planning? Usually, development teams are given a plan which may be unrealistic given the complexities of delivery. In such scenarios, teams have to deliver challenging plans under unbelievable timeframes.

The outcome of the Sprint Planning is the Sprint Backlog. The Sprint Backlog is simply a list of Product Backlog Items that will achieve the Sprint goal/s that the Product Owner believes will offer the most value.

What is the Daily Scrum?

The Daily Scrum is a short planning and synchronization event.

Remember the Sprint Backlog that the team generated during Sprint Planning? The development team pull items from the Sprint Backlog and work on them during the Sprint.

Every day, the team meet for a maximum of 15 minutes to usually answer three questions about the work they are doing/have done.

  • What did I do yesterday to meet the Sprint goal
  • What am I doing today to meet the Sprint goal
  • What impediments/blockers are preventing me from accomplishing my task

Although the Product Owner and Scrum Master don’t have to be at the Daily Scrum, our experience over training, mentoring and coaching a few hundred teams indicates that Scrum Masters and Product Owners benefit from the Daily Scrum. If managers want to attend, they are silent, this collaboration event is for the team not for management.

The Daily Scrum is a short, sharp meeting. Anything taking longer then 2 minutes to discuss is continued after the Daily Scrum, interested people are invited to stay which frees the team to opt in to the conversation. We tend to encourage holding the Daily Scrum around 10 am so the whole team is present.

The result at the end of the Daily Scrum is

  1. A plan for the day
  2. Team awareness of what everyone is doing,
  3. A list of problems to fix and an
  4. Opportunity to ask for or get support.

The Sprint Review

This Sprint Review happens at the end of the Sprint. It is attended by the Scrum Team and key Stakeholders.

This is an event where

  • The Product Owner explains what has been done, for example did the team achieve the Sprint goal
  • The development team *show* what they have accomplished this Sprint, what issues they encountered (and overcame) and invite questions
  • The Scrum team (with the Product Owner leading) alongside the stakeholders discuss what is next to be done

We encourage a review of the actual work where possible; power points are a last resort. Sprint reviews lose value unless stakeholders are present, work to include them at Review events.

The Retrospective

The Retrospective is the final meeting in a Sprint. This meeting happens after the Sprint Review and is arguably one of the most important events. The Retrospective serves as a deliberate evolutionary mechanism for Scrum Teams to measurably improve.

Remember we said that the Sprint is like a mini project? At the end of most projects there is a lessons learned event. So the purpose of the Retrospective is for the team to review their own progress and surface the challenges/wins in their working practices.

Whenever the team is struggling, the Retrospective, if done well, will recentre and renew the team. The Scrum Master usually facilitates this meeting for the whole Scrum Team. Remember the Scrum Team comprises of the Product Owner, Scrum Master and Development Team.

Essentially the Retrospective is about gathering data on how well the team did during the Sprint. Some questions the team seek to answer could be

  • What went badly during the Sprint?
  • What did the team do well during the Sprint?

The team consider what they did well in addition to any challenges they encountered. Teams then generate actions to overcome the problems experienced in the last sprint and are carried forward to be worked on in the next sprint.

In this way the team improves every Sprint.

The Scrum Framework works for any team!

My teams and I have recently used Scrum to increase productivity in trading teams, marketing teams, sales teams and audit teams. Although we regularly help software teams, infrastructure teams and data warehousing teams increase productivity, resilience and creativity, we have consistently found that almost any team can realize the benefits of Scrum.

Who are we?

Fractal Systems are an active Agile Consulting and Agile Training business. We teach real Scrum with lessons learned from the field and help companies build useable agile skills within their teams.

If you want to learn how to do Scrum well, join us here for a training.

If you are a firm wanting the benefits of faster time to market, resilient, organised, self healing teams and leadership, please reach out to us via our contact page.