Easy Steps To Implementing SCRUM

by Gavin / March 24, 2014

So you'd like to implement SCRUM, and you like the idea of an easy approach? Well, look no further. Introducing our Easy Steps to Implementing SCRUM

First Things First

To begin at the beginning, you first need to get your team aligned with the business. If you are already part of a business unit, this may be a straightforward process. If you are a development-central organisation already serving multiple business units with multiple projects, it may be more of a challenge.

A word about sharing teams. While it's possible to split a team across multiple projects, it's not recommended for organisations starting with SCRUM due to the complexity involved. Avoid doing this until the team really gets its legs under it.

As a corollary to the above, it's best to start small and work your way up. Pick a low-risk everyday project and run with that. This will keep things simple while the team gets up to speed on SCRUM. Once you've got your target project decided on, nominate at least one person to be dedicated to this project as the product owner. This person will be responsible for knowing what is required to get this project done, prioritizing the work, convey requirements to the team. This person should be an excellent communicator and willing to commit considerable time and energy to the project.

If you can't do the above right away, it's time to take a step back and review your organization. You need to have a team together that can communicate with clarity about objectives, requirements, priorities, and deliver on time. These are critical attributes for the success of your team.

Enter the Scrum Master

Ok, now that you're aligned and organized, it's time for some SCRUM. To keep things on track, you need a SCRUM Master. This person is responsible for the overall team, supporting, coaching, and guiding them through the SCRUM process, removing any roadblocks along the way. Think of the SCRUM Master as the captain of the ship - he's got a team put together that does the actual work, but it's up to him to keep the ship on track, and focus on the bigger picture. Once the SCRUM master is in place, let's fire up the development machine!

Get The Product Backlog Rolling

Simply put, the product backlog is the list of things that need doing, in prioritized order. In the SCRUM process, anyone can add anything to the product backlog, but only the product owner can prioritize items. As items come up, like that nifty new feature light-bulb that went off at midnight, you can add them to the backlog and the product owner will prioritize it.

Typically, product backlog consists of the following:
- Features
- Bugs
- Technical tasks
- Acquiring knowledge

The most often used approach for a SCRUM team to add features to the backlog is in the form of user stories. These short, simple descriptions of the desired functionality/outcome are told from the perspective of the user. For example, "I want to click this button and have x, y, and z happen. And if it fails, I want a message to pop up and tell me why."

As there are no differences between bugs and new features (each describes something that a user wants), bugs are added to the backlog.

Knowledge acquisition and technical work also belong on the scrum backlog. Technical work would include things like "upgrade all developer's IDE to the latest version". And knowledge acquisition would be a backlog item requiring research into the latest version of jQuery vs other JavaScript libraries.

Prioritize the Backlog

It's the product owner's responsibility to prioritize the backlog. Topping the list are items that need doing straight away. As you get to the bottom of the list, the items may get fuzzier (ill-defined) - this is ok, the definition will come when it's needed. The prudent product owner will keep off the list items which are unlikely to ever be done, or are so far over the horizon that including them now would just be a distraction. When bumping items or removing items from the list, it's important for the product owner to explain to the item author why it's being moved or removed. Communication is key here.

The well prepared product owner attends the sprint planning meeting with a list of prioritized items, and presents the top priority items to the team. The team then in turn thrash out which items they're sure that they can complete during the upcoming sprint. These items are then moved from the product backlog to the sprint backlog. This breaks down each scrum backlog item into one or more sprint backlog tasks. Divide and conquer is the rule here for effectively sharing the work amongst team members.

Plan your sprint

Ok, now that we have the backlog items on a list and the list has been prioritized, it's time to plan the next sprint. Sprint planning involves a meeting with all team members - all hands on deck! The product owner will go over the backlog, and the team members will do some back and forth on which backlog items (stories) will be included in this sprint. Once that's decided, the features are broken down into sprint tasks and assigned to team members.

Ready, set, sprint!

Finally, we're where the rubber meets the road. Time to get cracking on those tasks. During the sprint, there's typically a structured approach to getting things done. This typically involves the daily SCRUM meeting, at which the following typically takes place:

- Discuss what's been done so far
- Identify upcoming work for the day
- Note any roadblocks or impediments that have cropped up, and figure out how to resolve them.
- Sprint backlog is updated (note time remaining for each task)
- Update the sprint burndown chart.

Sprint Review

As each sprint ends, a sprint review meeting is typically called. At this meeting, the team shows the product stakeholders what has been accomplished during the sprint. Usually this involves a working demo of the new features that were implemented during the latest sprint.

By convention, the sprint review meeting is kept intentionally informal - typically powerpoint slides are banned and short prep time allowed. A sprint review meeting should not be a distraction to the team - rather, you want something that is just a natural outcome of the sprint. Participants in the sprint review will typically include the product owner, the scrum team, the scrum master, customers, developers from other products, and management.

During the review, progress is assessed against the sprint goal that was set during the sprint planning meeting. Ideally, every backlog item brought into the sprint will have been completed. Even if this is not the case, if the overall goal of the sprint has been reached, the sprint is considered a success.

Product Release

As early as possible, you want to release a tested and working version of the product. The first version may be light on features, but it will be a basic working model.

Sprint Retrospective

So you've got a good SCRUM team a-building. This is good, but no matter how good your team is, there is always room to improve things. The team should schedule brief dedicated periods at the end of each sprint to reflect on how they could improve. This is typically during the sprint retrospective stage. The sprint retrospective is typically the last step in a sprint. Some teams do the retrospective immediately after the sprint review. The entire team should participate - SCRUM Master, product stakeholders, etc - should all be there. It usually doesn't take long - typically less than an hour is more than sufficient. Sometimes a hot topic will crop up and cause long discussions, but this is also what the retrospective is for.

No matter how good a SCRUM team is, there is always opportunity to improve. Although a good SCRUM team will be constantly looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and to find ways to improve. This occurs during the sprint retrospective.

The sprint retrospective is usually the last thing done in a sprint. Many teams will do it immediately after the sprint review. The entire team, including both the SCRUM Master and the product owner should participate. You can schedule a SCRUM retrospective for up to an hour, which is usually quite sufficient. However, occasionally a hot topic will arise or a team conflict will escalate and the retrospective could take significantly longer.

Many are the ways to hold a sprint retrospective, but one of the most effective is the start, stop, continue method. It's a simple and effective way to look back and review the sprint. Under this approach, each team member identifies specific items that the team should start doing, stop doing, and continue doing. This can take the form of just having team members shout out items of concern, and have the SCRUM Master list them on a whiteboard, or sheets of paper can also be used for each team member to write down their choices. After a list of ideas has been fleshed out, team members can vote on specific items to focus on for the upcoming sprint.

So that's it - once you have this system down and your team is firing on all cylinders, you should find a vast improvement in your product output, customers who are much more satisfied, and a growing bottom line.

Subscribe to newsletter