A Practical Scrum Overview

I first encountered the Scrum methodology, as an agile way to build products, approximately 7 years ago. I had just started a new job in Paris at a new fangled startup as the mobile tech lead. I was going to be working on an iOS app. Up until that point in my career I had been exposed to several project management paradigms loosely based around Waterfall or the Critical Path Method, so to begin working with the iterative nature and the flexibility of Scrum was new and refreshing. I haven’t looked back ever since.

This post aims to describe the steps required to be taken by teams wishing to adopt Scrum. Many books have been written on the topic. Two of my favourites are Scrum and XP from the Trenches and Scrum — A Pocket Guide. There are also many online sources, such as Scrum Guides, that explore Scrum in depth; analysing each step and providing a plethora of use cases that might suit your team, product or organisation.

My experience so far has led me to believe that Scrum can be applied to almost any situation and at almost any point of a product’s lifecycle. Certainly though, there is some vernacular to become familiar with. However, all that is required is just one person with previous experience, or a person with the willingness to learn. You can begin with applying the fundamental steps and roles to a new project or a project that has already begun. You will continue learning along the way.

The Scrum Workflow

Scrum roles

The Product Owner

This person is responsible for the product as a whole. Their key responsibility is to convey their vision to the rest of the Scrum team in order for them to execute on it and build something tangible. They must typically have an in depth understanding of the product, its users, the competition and industry trends. Their background could be anything, but experience in product management is certainly advantageous. Practically, product owners perform their role by creating tasks and stories in the product backlog and prioritising them prior to the sprint planning meeting.

The Scrum Master

This role holds a special place in my heart. Maybe because I have played that role on several occasions. This person is responsible for assisting their fellow team members to achieve their goals. By definition the Scrum teams are self-managing and the Scrum master works in concert with that. In addition to providing furtherance for the team in order for them to realise their objectives, they are also responsible for removing blocking issues while working with the product owner. They communicate with customers, users, stakeholders and collaborators in general. They also shield the team from distractions such as new tasks that were not in the sprint backlog from being injected in there.

As a side note, I’ve seen teams, typically very small ones, run their product without a Scrum master. Whatever reason you might have, someone will have to pick up these responsibilities and therefore will probably be sidetracked from their primary tasks; but if you try it and it works out, good for you!

The Team

A Scrum team is a collection of individuals working together to deliver the requested and committed to, product increments. They are small, between 5 to 7 people. They are also responsible for translating product backlog items into sprint tasks; breaking them down into smaller tasks where appropriate. They have to assign estimates to each task and implement them. In other words they maintain the sprint backlog.

User Stories & Tasks

Stories contain multiple types of work, while tasks are restricted to a single type of work. Consider breaking up user stories into tasks. User stories can be found in the product backlog as they have been created by the product owner. These are usually phrased in a way that can be meaningful to end users. They can be phrased like so for instance:

As a user I want to <some action or achievement> in order to <some reason>

When they are written this way you may quickly discover that a user story can be broken down into many tasks by the Scrum team. For instance a user story might require a designer and front end coder. Maybe there is some networking on the front end that requires some infrastructure work on the backend. These tasks can be defined by the Scrum team and added into the sprint backlog.

A collection of user stories can be grouped up as an epic story. Individual tasks, such as an IDE upgrade for instance, don’t have to be part of a checklist of which a user story is composed of.

Your Product backlog

The product backlog is a collection of user stories and tasks. It’s a prioritised list, with the priority of each item determined by the product owner. The most important or urgent items are placed at the top. What I fancy about Scrum is its iterative nature. A product backlog is not an exhaustive list of all requirements. Instead it can can be a list of the desired product features you have in mind; that could be revisited, interlarded and embellished. Items in the product backlog can be expressed as user stories or tasks.

Tasks, Stories & Epics

Sprint Planning, Estimation & Story Points

Once your product backlog has been refined with all prioritised user stories, the Scrum team can begin the sprint planning process wherein they will transform the product backlog user stories into sprint planning tasks. Here, you make estimates as a team rather than as an individual.

Sprint Duration

At the beginning of the sprint planning meeting you must be sure that all team members and the product owner are present. Include, where applicable, testers, designers, product managers and developers. Once everyone has gathered, a team decision must be made for what the duration of the sprint will be. That could be between 1 week to 1 month. You can choose to skip this decision making process altogether since you might have previously decided to have a standard sprint length duration of 3 weeks for example. I cannot recommend this highly enough since in my experience standard sprint lengths give your team a great flow and over time help individual team members give precise and accurate estimates on product backlog items. My favourite length is 2 or 3 weeks for a web product or mobile app and I’m quite fond of 4 weeks also. Anything above or below that seems like a lifetime or to be impractical respectively. If you’re getting started with Scrum or a new product you might want to experiment with a couple of durations and see what works better for you and your team.

Product Backlog

Go through each user story or task in the product backlog along with the product owner. For each item they will provide details and clarifications. They should mention what they perceive to be pitfalls that might need more nuanced descriptions. The team might try to poke some holes in the logic or flow of certain items that will be promptly plugged during this part of the meeting. The designers will add their own perspectives too. The product managers will go into detail and communicate their own expectations. Repeating the above process for all items will assist everyone to gain an understanding of what is expected of the current Sprint and make Task creation and estimation more streamlined. If you miss out on something it’s all good. Team members will be available. Questions from everyone towards everyone related to a particular Story must be encouraged to be posed as much as possible.

Creating tasks

At this point you are ready to create tasks for your sprint. You can go through each user story or requirement in your product backlog. For each of these you can break them up into smaller tasks in whatever way you are comfortable with. You can break them up into traditional software development lifecycle items such as documentation, unit testing, design and development, and for each of those you can break them up further.

Story Points

You have started creating tasks and it is time to estimate what the required effort for completing each Task is. This is not a unit of time. One story point represents an amount of effort only. A common, and personal favourite, of story point values is the Fibonacci Sequence which is 1, 2, 3, 5, 8, 13, 21, 34 and so on. You could choose 21 to be the maximum value and try to break up bigger tasks into smaller ones. That’s dependant on the product you are working on but for a web product you will certainly almost always be able to do that.

Burn down chart: Remaing Work vs.Time

Since a story point doesn’t represent a time value it will mean a different thing for each Scrum team member. During the estimating portion of the sprint planning session the Scrum team could identify a base task that will hold the same story point value for everyone; or approximately enough. Then, each team member can go through the task list and assign points to their own tasks. Newcomers to Scrum will discover that after a number of sprints they will be able to gain a nice sense of their velocity.

The Sprint & Velocity

The Sprint is synonymous to an iteration. It is a unit of time that encompasses the beginning of the total tasks and user stories implementation, and ending when a product increment has been achieved. Product increments can be defined as a release which is a version of a product that can be be delivered to a customer, a set of users or to another team. A sprint is a time-boxed endeavour meaning it’s constrained to a defined duration. These durations could range from a week to a month or two. From my own point of view it seems that 2 to 3 weeks is a popular choice. Sprints are of fixed length for the product lifecycle even though it’s not unheard of to have variable iteration lengths for each successive sprint. I would caution against having a dynamic sprint length so that over time your team velocity can be measured consistently.

Velocity is the average number of story points completed by a team across iterations. It is useful in assisting us to understand our teams limits and our delivery capacity each sprint.

Work that can be completed in a sprint

If you are working with multiple teams, please avoid comparing team velocity. Velocity is not a measure of comparing teams but rather one of helping them improve their timing and product increment delivery capacity individually.

I’ve noticed that the few times I’ve introduced Scrum to an organisation while trying to convince them to adopt it as their methodology of choice, people’s eyes always light up at the sounding of the word sprint. It’s such a positive choice of a word for what it represents: A flexible, velocity driven approach to delivering a product increment. As a synecdoche it is what inspired me at my earliest introduction to it.

Done?

If you’ve decided to implement Scrum with your team, you are committing that at the end of a sprint you will have a shippable product or product increment for your users or customers. This means that the tasks and stories in your sprint backlog have been designed, developed, tested and quality assured. If these criteria have been met, the feature is done.

Once each user story, by way of the tasks that it’s consisted of, and each individual task that is in your sprint backlog has met these acceptance criteria the product owner can review them in order to evaluate that they meet their standards. Once they have accepted each story or task it is done.

What each team defines as done can, or even better must, be decided beforehand but at the end of the day it’s done if it can be shipped to a customer.

Get up! Stand up!

Otherwise known as the daily Scrum meeting, or “scrum”. I prefer using the phrase “stand up”. These meetings are typically held every single day at the same time, ideally at the start of the work day, and all team members are expected to attend. This meeting can be held at the same location or remotely via skype or a hangout. The purpose of this meeting is to frame the team’s endeavours for that day for everyone’s benefit.

During the meeting each person speaks in turn and mentions the following

• What they worked on yesterday
• What they will work on today
• Are there any “blocking issues”

A civil, quick and efficient standup builds a tight and concrete relationship among team members over time. It is easy to consider this meeting as a status update on current progress which in a sense it is. A deeper approach is to see it as what each Scrum team member has committed to another team member, or to the sprint progress.

By having each team member mention what they had been up to the previous day and current day, a clear picture is painted for the team’s benefit on what work has been done and what remains to be accomplished. The scrum master is responsible for removing blocking issues either on their own or by assigning a scrum team member to do so. Practically, each team member takes their turn on addressing the above bullet points. It could take approximately 15 minutes for a 5–7 person team but it could take a bit longer if there is some off topic small talk beforehand. A practice of several teams I’ve been involved with is to have calendar events for this meeting already setup until the far future.

Sprint review

Towards the end of each sprint a review meeting is held with everyone present if possible. That would include at least the product owner and the Scrum team. Each team member takes their turn in going through each task that was assigned to them for the current sprint. This is an informal meeting and progress and accomplishment is communicated either by description or a product demo. Others that can be present at the review meeting could be users and customers. This review is how the sprint is assessed in terms of its success. Ideally all items in the sprint backlog are done. Each item that isn’t done, gets bumped back into the product backlog to be completed next sprint. A successful sprint delivers a product increment.

Sprint retrospective

The Scrum master will organise this meeting at the very end of the sprint. The usual suspects could attend. People can discuss what went right but most importantly what went wrong and what measures could be taken so the same issue doesn’t pop up in the next iteration. The team should be able to answer the following questions:

• What went right during the iteration
• What went wrong during the iteration
• What could be done differently in order to improve?

What usually comes out of this meeting is a list of recommendations, ideas, and new processes that will help the team improve. It’s rewarding for a team to be able to self-identify issues it might be having and promptly improving their own processes in order to remove them.

Getting started

You can check out this template board from trello. Every pillar of Scrum discussed above has been represented as a column on the trello board which represents your product.

In conclusion

If you decide to adopt the Scrum methodology, over time you will start seeing the results in your product and, most importantly, your team. Your sprints will make your project iterate faster and improve. Your users will be able to regularly provide feedback, comments and remarks that you will hopefully be able to loop back into your product quickly. Your team members will gain confidence in their ability to self manage, identify their issues quickly and become more productive. And of course your customers will love the predictability and frequency of your releases.

Thank you.

And thanks to @BashaChris for this posts beautifully crafted hand drawn diagrams.