Scrum 101 : Introduction to Scrum
According to Gary Convis, president of Toyota Motor Manufacturing Kentucky, the role of a manager in a healthy, thriving work environment is :
“to shape the organization not through the power of will or dictate, but rather through example,
through coaching and through understanding and helping others to achieve their goals”.
Scrum embraces this approach on a number of levels, and many of the processes, ceremonies and artefacts are designed to further this collaboration. In this article, I provide a very basic description of the Scrum framework.
What is Scrum ?
Scrum is a lightweight team level framework typically used for software development projects, although it can be used for non-software projects as well. It’s power comes from it’s simplicity which facilitates rather than inhibits output producing activities.
Scrum incorporates a number of Agile principles such as : collaboration, team empowerment, project visibility, time-boxing and continuous improvement. It is frequently complemented by Agile software engineering practices popularized by XP (Extreme Programming). Practices such as pair-programming, test-driven-development, sustainable pace and continuous integration further enhance quality and productivity of teams using Scrum and hence are popular additions.
The primary objectives of using an Agile or Scrum methodology are :
- Delivering according to customer wants and needs quickly and efficiently.
- Maximizing client trust and visibility during the process.
SPRINTS : Delivering functionality frequently
The project is divided into a series of fixed time boxes, known as Sprints. These should be of the same duration and are typically between 1 – 4 weeks long. There are no gaps between sprints, so these form a continuous cycle of deliverables. A core principle of Scrum is to ensure that each Sprint must have a deliverable which is of business value. This ensures progress that is regular, visible and obvious from a business perspective.
So, in other words within Scrum :
- The Sprint cadence should be kept consistent – providing a ‘project heartbeat’ which instills discipline, and allows the team to get accustomed to frequent delivery and release cycles.
- At the end of each Sprint we should always try to create a Potentially Shippable Product (PSP) increment.
- We include all activities to get the PSP increment ‘Done’ within the sprint.
The duration of the Sprint is dependent upon a number of factors such as :
Project volatility – the amount of change the project is likely to be subject to. There is an inverse relationship between volatility and Sprint duration. If the project is likely to be subject to a large amount of change, it is important to have a smaller Sprint duration, and vice versa.
Team proficiency – many teams new to Agile struggle to incorporate XP practices such as continuous integration, test-driven development and other practices. Without the ability to be able to build, test and release software quickly, it is difficult to have short time-boxes of 1 or even 2 weeks. Additionally, teams may struggle to split requirements to suitably small sizes for completion within a short Sprint.
Scrum has a number of Products (Artefacts), Processes (Ceremonies), and Values
Scrum has a number of products (Artefacts), processes (Ceremonies), and Values. We’ll discuss this over the next few sections. We’ll begin by discussing Artefacts first, the first of which is the Product Backlog.
Artefact 1 : Product Backlog
This is simply a list of prioritized requirements for the project. An essential element of Scrum is the emphasis on the creation, ownership and prioritization of the list by theProduct Owner.
Agile projects constrain time, cost and quality, allowing variances in scope. This approach makes it essential that the business functionality included within the project is prioritised according to what is most valuable to the customer. Any reduction in scope or removal of requirements will in this way be made to the ‘least valuable’ business functionality.
There are two main reasons why the approach to vary scope is deemed acceptable :
- Using the Pareto Principle (80/20 rule), it is likely that with delivery of a large proportion of valuable functionality, any scope reduction of the least valuable functionality is likely to have a minimal impact upon the final viability or ROI of the product or service.
- Ken Schwaber (founding father of Scrum) talks about an incredible Industry statistic that states 65% of software functionality is never used, and so the ‘least valuable’ functionality which is descoped is unlikely to be missed.
The Product Backlog is not a static list of requirements. It is continuously evolving throughout the duration of the project and contains requirements of varying levels of detail and size. Requirements are also called User Stories – the name depicts the fact that the requirement represents real business value to the user or purchaser of the system.
Stories at the bottom of the list may be far off and may or may not ever get done. Things down the bottom are likely to be fuzzy and ill-defined. The principle is ‘don’t waste time defining things you may never get to, or not get to for some time’. If something is a bad idea, the Product Owner should explain to whoever requested it why they are removing it from the backlog. However, if something’s not such a bad idea, although never likely to be done, just put it in its rightfully low place on the backlog and explain to the requester where it fits within the project priorities.
Additionally, a backlog may contain anything. Anything relating to the product that is. Bugs. Enhancements. Whole projects. Issues. Risks. Anything.
Artefact 2 : Sprint Backlog
The Sprint Backlog refers to the work (taken from the Product Backlog) which needs to be completed during the current Sprint. Finishing the stories in the Sprint backlog should be the primary focus of the team during the Sprint. This backlog is owned by the Scrum team and only they are allowed to change how they deliver the stories. The stories should not be changed once a Sprint has started.
Artefact 3 : Scrum Burndown Chart
‘Everything should be made as simple as possible, but not simpler.’ ~Albert Einstein
In my humble opinion, the Scrum burndown chart is arguably one of the most profound additions to the genre of project management in recent history. Its power, you might even say genius, is its simplicity. Whereas other project tracking approaches were complicated and cumbersome, the Scrum Burndown principle is derived from the primary objective of project tracking – ‘ensuring that the project deliverables committed to are delivered on time’.
Scrum burndown charts simply track how far we are to achieving this objective in hours remaining. At the end of each Sprint, we should have 0 hours remaining. In other words, it is a graphical representation of time remaining with ideal and actual burndown lines. To benefit from the Agile principles of openness, collaboration and visibility, these charts are often drawn on a project board for all to see.
There are a number of ceremonies within the Scrum framework.
The Daily Standup
Traditional waterfall projects typically have weekly team meetings that may last an hour or more. The Daily Stand-up is a short meeting of up to 15 minutes, which involves the whole team standing in a circle, frequently around the team’s whiteboard. There are a number of reasons for this approach :
- To maintain maximum work output / throughput (aka project velocity) it is important for the team to work together and remove obstacles to progress (aka impediments) quickly.
- To foster a spirit of co-operation and collaboration within the team.
- To gain visibility and understand the progress of the team on a daily basis.
- As all work stops during a team meeting, the cost and impact of this is recognized and so meetings are deliberately kept short.
Ideally the Daily Standup should be conducted in the morning so that each team member can think about what they have done the day before, what they intend to do that day and raise any impediments to progress.
Exceptions to the ‘first-thing in the morning’ meeting may be where a team is not co-located. In such a situation, it may be held later on to adjust for time-zone differences. If anyone is unable to attend the meeting, they should notify the team and provide their standard input. Late attendance is discouraged, some teams may ask late attendees to pay a ‘fine’ to the team.
Three questions must be answered by each person :
1. What have you done since the last Daily Scrum Meeting regarding this project ?
2. What will you do between now and the next Daily Scrum Meeting ?
3. What impedes you from performing your work as effectively as possible ?
Note the subtle change from the standard wording, the above is carefully crafted to ensure clarity and focus (in the first question), commitment (in the second question), and expectation (performance must be as ‘effective as possible’).
The Sprint Review meeting is held at the end of each sprint, providing an opportunity for the team to demonstrate functionality created during that sprint. An important part of the Sprint Review meeting is to get feedback from customers so that the product can be updated to be in alignment with the customers needs.
During the Sprint Review we only demonstrate functionality that is ‘done’, that is it meets a pre-determined definition of this phrase. It should be displayed ideally in an environment that is as close to ‘live’ as possible.
The team presents :
- The sprint goal.
- The sprint stories committed to.
- The sprint stories backlog done.
Stakeholders are asked for :
- Feedback based on the functionality demonstrated.
- Feedback on functionality not delivered or functionality which does not behave as expected.
After the Sprint Review meeting, the Sprint Retrospective meeting is held to continuously improve productivity and team work. The Sprint Retrospective is based upon the Agile principle of continuous improvement. By designing this principle into the Scrum framework, at the end of every sprint, we hope to continuously improve team performance and project velocity in a step-wise fashion Sprint by Sprint. We do this by evaluating what works well, what doesn’t work so well, brain-storm ideas and adapt our approach accordingly.
Within each meeting we discuss :
- What went well? Try to make sure it’s repeated next time.
- What could have gone better? Try to understand why.
- What the team will do differently in the next Sprint? Try to pick a few actionable points that can actually be introduced into the next Sprint.
Actionable items that can be added to the next Sprint may appear as high-priority non-functional product backlog items. Retrospectives that don’t result in change are pointless, as the objective is to find ways to improve performance, teamwork and team morale continuously.
Sprint Planning Meeting
Attending : Product Owner, Scrum Master and Scrum Team.
The primary objective of the Sprint Planning meeting is to focus on What needs to be delivered during the current Sprint, How to deliver it, and Who is responsible for the task. The entire team including the Product Owner is required to be at this meeting. Planning is typically split into two sessions :
Session One : Create the Sprint goal, and transfer product backlog items to the Sprint Backlog (What).
Session Two : Break down stories into tasks (How), estimate tasks/stories and (optionally) seek commitment to tasks (Who).
The Product Backlog must be prepared for Sprint Planning in advance. This may happen in a separate meeting towards the end of a Sprint to plan the following Sprint. This meeting is frequently referred to as a ‘Backlog Refinement’ meeting. The output from the Sprint Planning session is a Sprint Backlog of stories, tasks, task estimates and (optionally) who will perform the task.
One of the major differences between Agile and traditional waterfall projects is the way in which the customer is viewed. In traditional project management approaches, the customer is viewed as separate from the team and frequently as an adversary to be kept away from the team. Agile thinks of the customer as part of the team and incorporates them within the team. A new role called the Product Owner has been created within the Scrum framework whose responsibilities and authority spans multiple traditional roles such as the customer, project sponsor, product or project manager. In essence they are responsible for driving the product vision and managing the Product Backlog.
The Product Owner is required to be available during the team development process, guiding and contributing, elaborating and refining requirements, ensuring the priority of features being delivered is based upon the highest business value and helping develop business focused tests.
The customer (Product Owner) is responsible for four main things :
- Defines WHAT (stories)
- Defines WHEN (priorities)
- SIGNS OFF Sprints and Releases
- Provides VISION for the team.
The role of Scrum Master is less of a ‘command and control’ type project manager or team leader and can be viewed as a facilitator, coach or mentor. The Scrum Master is someone who guides the team, removes obstacles, stops external interruptions, ensures quality, facilitates team and individual productivity, and is responsible for facilitating a happy and empowered team environment.
It is important for traditional project managers taking the role of Scrum Master to appreciate, and then embrace this philosophy. The Agile philosophy is essentially one of empowering and devolving responsibility down the management chain to the ‘doers’. As such it is important to resist command and control style dictate that is normally associated with project management. The team is trusted to self-organize, and so letting go can be difficult at first for traditional project managers.
So, In Scrum …
- Everything is Time boxed : Things don’t go on forever.
- Constrained size of team : Smaller teams allow for focused and intense effort.
- Multi-Skilled Teams : Teams should be cross-functional with skills in different areas required to fulfill the project objectives.
- Devolve Responsibility : Uses principles of lean thinking – ‘the best people to know what to do are the people doing the work themselves’.
- Outcome, Not Process Oriented : Have something useful and complete at the end of the time-box.
- Be Visible Quickly: Everyone knows where you are at every time box.
- Leave the team alone : Interrupting the team from their primary objective, significantly reduces the rate of progress.