Rather than covering techniques (like release planning, burndowns and sprint tasks) the guide focuses on what makes Scrum Scrum: the roles, events and artifacts, and the set of rules that bind these together.
In an introduction to the changes from the 2010 Scrum Guide, Schwaber and Sutherland compare the Scrum Guide to guides for games: rules (pass go, collect $200) are different from strategy (get to three houses as quickly as possible, because this is when the rent bumps up dramatically). They write:
The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on.
Strategies for playing Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those of us working on a revision to the Scrum Guide, this meant that all tips, optional practices, and techniques should be removed from this document. This was done along with refining some language to correct some long-standing misunderstandings about Scrum.
Given the Introduction to Scrum workshops we’re running at the moment, we were keen to look at the Guide in terms of how it can help us teach people about Scrum. Here are some of the passages that really grabbed us:
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
We often explain that a key part of the Scrum Master’s role is to clear impediments that are stopping the team from working as well as they could. Here, we like the notion that the Scrum Master isn’t just clearing blocks, they’re teaching people to proactively stop the blocks from happening.
… each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
We’re frequently asked whether all the events in Scrum (stand-ups, planning meetings, task estimation, demonstrations, retrospectives) are really necessary. We usually say that of course you should use the structure and methods that suit you best – but that if you’re not following the Scrum events, you’re not using Scrum.
We also try to explain how you can go through the motions of Scrum events without getting the benefits. Thinking of every event as an opportunity to inspect and adapt, and to create transparency, reminds you of why these events are held and the spirit in which people need to participate.
A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, a Product Backlog also exists.
The Scrum Guide’s section on the product backlog really emphasises that the product backlog isn’t there just to get you to an initial release – it is a long term commitment. In fact, the Guide states that the product backlog will become ‘larger and more exhaustive’ after launch. Interestingly, the Guide also dwells on the role of team members in contributing to product backlog grooming, not just the product owner and stakeholders/subject experts.
Overall, the 2011 Scrum Guide is concise (a slim 16 pages), focused and a useful resource for newbies and experienced Scrum practitioners alike. Enjoy!
More reviews of the differences between the 2011 Scrum Guide and earlier versions:
In Scrum, the definition of done tells us when a feature is completed to a releasable standard. It sits above the individual acceptance criteria for each user story. For example, here’s the definition of done for development stories from one of our projects:
committed to source code repository
passes appropriate tests for story (including cross-browser testing)
tests written and run on integration server
accepted by product owner on UAT (unless story asks otherwise)
documented (well-commented)
cross- browser testing of interface elements
readme updated if applicable
change log updated
Adding the definition of ready to the definition of done
Recently, we’ve been looking at the definition of ready – the criteria a user story has to reach before it can be handed over to the team. You can think of the definition of ready and the definition of done as two key points in the sprint cycle – one defines when a story is ready to go in, and the other defines when a story is ready to come out.
Jeff Sutherland and Carsten Ruseng Jakobsen have described a definition of ready as a simple concept that depends on discipline and creates stability in a sprint. It’s designed to stop time being wasted when it’s discovered that user stories are missing important pieces of information that means they can’t be started or completed.
A definition of ready gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, as Sutherland and Jakobsen observe, a definition of ready can improve the flow and stability in a sprint.
A sample definition of ready
Here’s a definition of ready we’ve developed for one of our projects:
The business value is clearly articulated (in the format of ‘As a type of user I want some goal so that some reason‘)
The story has clear and concise acceptance criteria which describe all of the features of the story. Details are captured as a narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system.
Once the acceptance criteria have been met the story is complete
No external dependencies block the story being completed
Story identifies external expertise and provides contact details.
Many of the points (for example, 2,4 and 5) reinforce the usual expectations of a good user story. Some are designed to trouble-shoot in advance: for example, 7 and 8 are there to help the team work as efficiently as possible, by ensuring they’re not being held up by business processes outside of the team, and have ready access to any expert help they need. And some are small tweaks that add efficiency in the longer term – for example, point 3 ensures we have a short headings for the user stories that make them easy to scan in Pivotal Tracker.
In conclusion
Of course, having a definition of ready doesn’t mean there won’t be occasions during sprint planning meetings when gaps are found in the preparation or understanding of a user story. It also doesn’t mean the team no longer has to talk the stories through with the product owner during these meetings, and throughout the sprint. But it does mean you’re creating the best possible conditions for optimal productivity in the sprint.
The Boost office was buzzing yesterday when we got a call from Rich Chetwynd and Nicole Fougere from Litmos.com to let us know they’d chosen our entry for IntuitionHQ (our online usability testing tool) as the winner of their Booster Seat 2011 competition.
As a result, two people from Boost will be winging their way to San Francisco in November and spending a month working out of The Landing Pad in the SOMA district. You can read more about this on the IntuitionHQ blog and this Idealog story, but we’d just really like to say a huge thank you to Rich and Nicole for their amazing generosity towards New Zealand businesses, and this incredible opportunity.
All of this is really useful, really interesting information, and we hope that you are all getting value from it. From these posts, and through our Twitter stream one of the questions we’ve been getting most frequently is about the history of Scrum – where did it come from and why did it turn out the way it did?
To answer this question we’ve got a video straight from the source with one of the founders of Scrum, Jeff Sutherland.
Check out the video below to learn about the history and reasoning behind Scrum.
Where did Scrum come from?
The logic behind Scrum as a development methodology is really very interesting, and Jeff Sutherland does a great job of explaining it. There are a few key points I find particularly interesting, and that are reflected in Scrum processes as we see them today:
Why other systems don’t work:
Specialised silos of activity leads to slower communication and add lengths to the development process – this makes sense as there is not enough communication between people with different roles so it makes it hard to achieve the goals or development milestones that they have committed to
How they developed Scrum processes
The roles of Scrum
To simplify the process they created teams with just two roles – a team and a team leader (aka The Scrum Master)
They found that the needed someone who truly understood the requirements of a project as well as representing the users, and so they came up with the role of Product Owner. This way every development cycle would add value for users and the business, and the team would have someone on hand who understood the requirements of each piece of functionality and could explain the reasoning each part of the project
The meetings of Scrum
Experience shows (and anyone who works in a large organisation can testify) that too many meetings slow down the development process; in order to speed up the process, the needed to reduce the number of meetings to a minimum amount
They found development should be done in short cycles of 2 to 4 weeks (aka sprints) – essentially so there is good communication, and each development cycle can be well estimated
You need a meeting at the beginning of a sprint to define what you are going to pull from the product backlog (as managed by the Product Owner), how you are going to implement and track each item from the backlog
Research from Bell Labs showed that teams were driven by daily meetings, but they wanted it to be a very short meeting of no more than 15 minutes, so all members of the team knew what was going on, what they were going to achieve and how they could help other team members
At the end of a sprint, you would demo real, working software to get feedback from the product owners and stakeholders of the project, so you know what’s working well and what’s not – that feedback cycle (aka a Retrospective) is what helps teams to improve and help development go faster
Reporting in Scrum
They needed to do a rethink of how reporting would occur in software development as the traditional method of using Gantt charts simply didn’t work as too many changes occur. They came up with the concept of a Burndown Chart so you could see a glance how fast the team was going, how much work was remaining and how much time was left to do it
They left the Burndown Chart up on the wall as a method of self reporting. Everyone could see the state of the Scrum at any time, and immediately know how much work was left to do.
They used a visual workspace (again, up on a wall) so you could see what needed to be done, what work was in progress, and what was done and tested at any moment in time
Scrum in a nutshell
So that’s more or less how Scrum came about – quite an interesting story really. Jeff Sutherland is evidently a very interesting character, and the thought that has gone into making Scrum as efficient is really very apparent.
Does this match up with your own experiences of Scrum? How does Scrum work for you? Did you enjoy your history lesson? Be sure to let us know in the comments below.
Want to learn more about Scrum? Be sure to sign up for our RSS feed, or follow us on Twitter and Facebook for more great information. Thanks for dropping by!
[Here's the tl;dr version of this blog post. Every Friday we run free workshops about Agile development here at the Boost offices in Wellington. To find out more, read on. To sign up, scroll down to the end of this post, or email [email protected]]
Here at Boost, we’ve been using Agile development practices – Scrum in particular – to run our internal projects for five years, and with our clients for three years.
We keep meeting more and more people curious about how using Agile might help their organisations. So a few months ago we sat down and developed a two-hour workshop, Introduction to Scrum, which introduces the main Agile ideas and practices, with a special focus on the Scrum techniques that we use. We tested the workshop with clients and other people, and got really good feedback.
In fact, the feedback was so good that we’ve developed and tested a second workshop, Writing Great Agile User Stories. This two-hour workshop is focused on understanding how user stories work within Scrum, and lots of hands-on practice writing user stories and acceptance criteria.
We’re now opening the workshops up to the world. There’s a workshop session available every Friday from 2pm to 4pm, and we’re alternating between Introduction to Scrum and Writing Great Agile User Stories. Further workshops are being worked on right now.
Workshop 1: Introduction to Scrum
The Introduction to Scrum workshops are run by Boost’s managing director Nathan Donaldson, a certified Scrum master.
We start off by talking about where Agile has come from, and how it’s different from traditional Waterfall development.
Then we’ll talk about the different roles in Scrum:
Product owner
Scrum master
Scrum team
We’ll cover off the core ‘artifacts’ in Scrum:
user stories
product backlog
sprint backlog
And then run you through the Scrum sprint rhythm:
sprint planning
estimation
demonstration
retrospective
After this, we’ll talk about some of the improvements we’ve seen in projects and organisations that have adopted Agile, like more communication, better specifications, less waste and less rework, better prioritisation and planning, and happier, more productive teams. And we’ll talk about the challenges that have to be overcome when Agile practices are introduced into an organisation for the first time.
And in the last five minutes we’ll run a quick retrospective on the session, so you can tell us what you liked and what we could improve. Continuous improvement is one of the core principles of Agile, and we apply it to these workshops too.
Workshop 2: Writing Great Agile User Stories
Writing Great Agile User Stories is run by Courtney Johnston, one of our project managers, a certified Scrum master and experienced Product Owner. The workshop is a focused and hands-on introduction to writing user stories and creating a product backlog.
You’ll learn
How to write user stories
How not to write user stories
How to write acceptance criteria
About Done definitions
How to create and maintain your product backlog
How user stories are estimated by the team.
As with Introduction to Scrum, at the end of the session we do a quick retrospective to figure out what worked well, and what improvements we can make.
The nitty-gritty
Who are the workshops for?
Introduction to Scrum
This workshop will be helpful for anyone involved in website and software development. We’ve had project managers, usability analysts, programmers, designers and writers attend, and everyone has found something useful in them. It doesn’t matter in the least if you’re public sector, private sector, work for a charity or a start-up, or are just plain curious.
Writing Great Agile User Stories
This workshop will be helpful for people who have already had some experience or exposure to Scrum, and who want to learn more about this particular aspect. It will be especially helpful for people new to or thinking of taking on the Product Owner role.
How many people can attend?
We cap attendees at 6 people; this is the best number for discussion and sharing experiences.
You can come along as a team – that way, you can talk about how you manage things currently, and what you’re looking to change. But we’re also happy for people to sign up in ones and twos; it’s just as useful and sometimes even more interesting to have a bunch of different perspectives in the room.
Where are the workshops held?
We hold the workshops here at the Boost offices in central Wellington. You won’t be trapped in a stuffy little room – it’s nice and spacious, with great views over Cuba Street.
What does this cost?
Nothing. The workshops are completely free, and completely obligation free.
We’re running these as free sessions for two reasons:
We really think people would benefit from using Agile methods to run their projects
We’ve learned a lot from the Wellington and international Agile communities, and want to keep the sharing going
