This article was taken from the January 2015 issue of WIRED magazine. Be the first to read WIRED's articles in print before they're posted online, and get your hands on loads of additional content by subscribing online.
Jeff Sutherland first published his manifesto for the Scrum management framework -- inspired by the rugby scrummage and prescribing small, multi-skilled teams and flexible planning -- in 1995. He's since implemented it at Google, Yahoo!, Adobe and Microsoft, which incorporates it into its development process. But it's not just for software. "I've seen Scrum used successfully to build cars, run a laundry, teach students in a classroom, make rocket ships, plan a wedding... You can even -- as my wife does --use it make sure that the 'honey do' list gets done every weekend," he says in his book, Scrum (Random House Business). Here's how to plan your life with Sutherland's system.
Scrap the business cards
"The first thing you want is small, cross-functional teams -- having lots of narrow specialists is a huge waste of time," says Sutherland. Other than general team members, the only two roles you should establish are: the product owner, who understands your customer, has a vision for the product and decides in what order things should be done; and the ScrumMaster, who's responsible for arranging meetings, facilitating communication and removing obstacles in the team's way. Both should avoid giving orders, but guide and assist the team to achieve goals.
Don't set tasks, tell stories
At every stage it's essential that team members know why they're building each individual feature, and what value it's supposed to offer the customer. This can get lost in a simple list of what needs doing. "Instead of tasks, tell stories from the point of view of the user," says Sutherland. For example. "As a customer, I want to see books organised by category, so I can find the types of books I like." Keeping this in mind while building each feature ensures that you're creating it to do exactly what your customer wants it to do.
Effort point the stories
Once you have a long list, called the backlog, of all the things that your customer will want to do with your product, you need to estimate the time that each will take to implement. Humans are notoriously bad at absolute estimates of time, but much more accurate at relative estimation. Instead of assigning each story a time period of days or weeks, assign it effort points relative to other stories. This allows you to order tasks by how long they'll take to achieve without making time commitments too soon.
Prioritise features
At the end of each of your iterative tasks, or sprints, your aim is to have a completed feature that can be demoed, to provide value to the customer as quickly as possible. "The product owner needs to assess which features will offer the most revenue, balanced against the effort that they will take to implement," explains Sutherland.
This won't work if your stories are big, overarching goals like "build a new engine". So for any stories that have particularly high-effort point estimation, break them up into smaller, more manageable pieces.
Plan your first sprint
Now you're ready to begin your first sprint, a set period in which you decide you're going to complete a certain number of items from the top of that list. "An ideal period should be between one to four weeks," explains Sutherland. For the first sprint it's your best guess as to how many effort points you should aim to complete, but make sure the stories you select will amount to a demonstrable piece of added value by the end of the sprint. "Rolling new stuff out every few weeks means you can get constant feedback on what's working and what isn't," says Sutherland.
Meet up daily
One of the most important principles of Scrum is that everyone should know everything. "In the early 90s, a Bell Labs study found that effective information sharing among members meant teams worked as much as 50 times faster," says Sutherland. Every day the team should gather for 15 minutes, standing up, with the ScrumMaster asking three questions: what did you do yesterday to help the team finish the sprint? What will you do today to help the team finish the sprint? What obstacles are in the way? This way, any problems are addressed immediately.
Have a sprint retrospective
At the end of each sprint you should have a meeting to ask broader questions about how the sprint went. The focus shouldn't be on blaming individuals, but identifying sticking points that can be eliminated for next sprint. Are your estimations of how much effort each task will take accurate? Are you focusing on developing the right features first? "The outcome of this meeting should be an improvement to the way you're working that can be implemented in the next sprint," says Sutherland. "The goal of Scrum is continuous improvement".
This article was originally published by WIRED UK
