In a previous post I talked about how I came to learn that I could teach Agile to lots of people at the same time. In writing that post I realized that it was a great illustration of self-organization. That realization was in the forefront of my mind as I ran the session “Hands On Agile Immersion” on March 10th at Agile and Beyond 2012 .
Although I’ve trained large groups of people on Agile many times over the last few years, it never occurred to me to create a video of the experience. This time, I decided to do it to illustrate large-scale self-organization in action. There were eleven separate teams with no appointed leader.
All I did was set up the learning environment, provide the materials, and give just a few instructions for each activity. The participants did all of the learning/teaching as a self-organized team on their own.
In the span of only an hour and a half, all 11 teams taught themselves the basics of 9 Agile practices as follows:
- Form cross functional, collocated teams
- Pick a software product to “build”
- Write 12 User Stories for that product
- Put the stories into a backlog ordered by business value with the help of a Product Owner
- Estimate the stories in story points using Planning Poker
- Plan a release using 2 iterations worth of stories
- Do all of the above as independent self-organized teams
The teams did self-organization so well, I was able to do capture lots of video clips of the session and only had to answer 4 or 5 questions about the mechanics during the whole 90 minutes of the session.
As always, one of the favorite things that people learned was “Planning Poker,” an Agile estimation technique involving special playing cards. I told people I didn’t need them back and I also gave away all of my extras. I brought 48 decks and they were all gone at the end of the session. Not even a single card was left behind!
A short video (4:10) of the session is available on YouTube .
Some folks from Macomb Community College made their own video (3:58). The “Hands on Agile Immersion” part goes from 1:25 until the end.
A burn-down chart can use anything for the units, such as hours or points, but originally Scrum’s burn-down chart tracked hours of work remaining in the iteration. Many people still use an hours-based burn-down chart as their primary measure of progress during an iteration. That’s a useful tool, but it is similar to tracking yardage in an (American) football game. It measures activity, but not accomplishment. After all, what percentage of a touchdown is 30 yards?
Working Software is the Primary Measure of Progress
One of the principles from the Agile Manifesto is “Working software is the primary measure of progress“. But burning down hours is measuring and reinforcing progress against a plan without any requirement to have working software until the end of the iteration. That’s pretty much the same as not having to have working software until the end of a waterfall release! This is one of the reasons that many people have moved away from burning down hours or supplemented it with other tools, such as burning up story points.
Burning Up Points to the Rescue
At the end of each day you tally up the story points associated with all of the stories that meet your definition of “done” and record the total on the chart. For instance, if you completed a 1 point story on the first day, nothing on the second day, and a 2 point story on the second day, your chart would have a 1 point bar for the first day, a 1 point bar for the second day, and a 3 point bar for the third day.
A points-based burn-up chart lets you see graphically day-by-day how much progress you are making towards your goal. It only records accomplishment, not activity, and allows you to see if you are on track or getting behind. To me, this is exactly what is meant by “Working software is the primary measure of progress.“
Won’t The Chart be Empty Until the End of the Iteration?
At first you may think that the chart will show that you are behind for most of the iteration and catch up only at the end when QA is able to start testing and marking stories as done, but whenever the chart shows something other than a steady march to the end of the iteration, here are some of the questions you should be asking:
- Are our user stories too big? Is that preventing QA from getting involved earlier?
- Are people working on too many stories at once?
- Are we unable to produce a stable build for QA to test?
- Are developers producing a bunch of problems and then going on to the next story instead of helping QA resolve the problem?
- Should the developers drop what they are doing and lend a hand writing automated tests?
- Use story points for estimation, it enables whole-team thinking such as this whole-team metric.
- Make stories as small as possible to get them done as fast as possible to keep the focus on accomplishment rather than activity
- Have as co-located and as cross-functional a team as possible to enable the fastest possible turn-around time on stories
- Enable the team to work as a team and to manage more things on their own
I was speaking to some fellow Agilists at an event recently about an Agile training course that I do that can accommodate up to 200 people at a time and they were pretty skeptical that it could be done. Later, I realized my path to creating the course …
The following books are the main books that I recommend as starting points for learning about the various aspects of Agile. While their is a fair amount of overlap each of them covers a specific topic. The one on leading self-directed teams is not stri…
By far, the talk that I am most requested to do is “Scrum and Kanban Like Chocolate and Peanut Butter”. I’ve given the talk all over the US and Europe, most recently in Kiev for Agile EE. Invariably, people come up after the talk and ask how to get sta…
A couple of years ago I first talked about applying the decoupling principle to Scrum. Since then I’ve turned a bunch of that material into a presentation called “Scrum and Kanban Like Chocolate and Peanut Butter.” I’ve made many updates to the presentation and presented it to a wide variety of audiences. One of the main points of the presentation is that all of the things in Scrum that are coupled to iterations can be defined in such a way that they are no longer coupled to iterations. I argue that once you have done that with everything, there is really no value left in an anchor point which anchors nothing. That is, there is no fundamental need for iterations in Scrum.
From time to time I’ve realized that I forgot to decouple something, figured it out, and added it to the presentation. For example, burndown charts, burnup charts, and per-story timeboxes. The per-story timeboxes were tricky to even notice because in Scrum we generally think of timeboxing at the iteration level, but in effect that also imposes a timebox on individual stories. If you remove iterations without taking this into account then you are also removing the per-story timeboxes.
But recently, buried among the many feedback forms from presenting at Agile 2011, I found three little words: “What about commitment?” Ouch. I had missed a big one! The Scrum team makes a commitment that is tied to an iteration. How could I have missed that?
As I thought about it more, I realized that I do actually address this point in an off-hand way when talking about decoupling story assignment from iterations. However, I am very grateful for the comment. It helped me realize that I had been effectively dismissing commitment as though breaking a promise with a shrug.
You may also be interested in the follow-up to this post, “Sticking to Estimates“
For those of you that have attended one of my recent talks on “Scrum and Kanban Like Chocolate and Peanut Butter,” here are the slides for the presentation. If you haven’t already attended the session, be warned that there are no speaker notes and clic…
There are three particularly valuable things that can happen during a Planning Poker session. They may also happen during any flavor of estimation meeting, but seem to be more likely when using Planning Poker.
I recommend that you never use a story size greater than 13. Most stories that are estimated at 8 points or above can be split into smaller stories. You should always be looking for opportunities to break larger stories into smaller stories. If you have an 8 point or larger user story, it is probably actually two or more stories in disguise. The bigger the story, the more likely your estimates are wrong and the more likely that you have many smaller stories masquerading as one large story.
For instance, you may find that a story that originally looked like a 20 point story was really two 8 point stories, one 5 point story and 2 three point stories for a total of 27 story points. Better to break that huge story down into its five constituent stories and estimate them each individually.
But remember, a story is only a story if it provides value to the user. Splitting a story up into “As a user I want the backend for X” and “As a user I want all of the UI for X” is not the right way to go. If you can’t create smaller stories that still provide user value, then the story is already as small as you currently know how to make it.
You may realize while discussing a story that the story contains a big unknown, something that feels like it won’t be resolved during the implementation of that story. In that case it is best to split the story up into a research story and the story itself. For instance, “As a developer I want to know how to XYZ.” That way, if you never do figure out how to do the unknown part, you haven’t invested any effort into the overall story. This technique should only be used as a last resort, but it is much better to do this than to know going in that there is a big unknown and have to pull the whole story out near the end of the iteration.
Lastly, you may decide that you just don’t have enough information to estimate a story. In that case, you should have a mechanism for informing the product owner such as marking the story “need more info.” There’s no point spending time on estimation if there is insufficient information to do so. You’ll just be glossing over the problem and producing a false sense of security.
Breaking out research stories and kicking stories back to the product owner may seem like procrastinating, but it tends to build good habits. It keeps the team from committing to work that includes research projects, clearly defining some stories as research stories, and keeping the product owner on his or her toes.
In summary, if you are mostly working on small user stories that have end user value, you are reducing the chance that you are putting something into the product that never gets used and you are also reducing the chance of starting work on something that never gets finished or has to be discontinued part of the way through. The smaller your stories, the smaller your risk and the less effort you’ve wasted when you run into problems.
Planning Poker is a useful Agile estimation technique (see previous post “Introduction to Planning Poker“), but it is even more useful when used in conjunction with whole teams, user stories, velocity, and story points. I refer to these five practices, used together, as the five essential ingredients of great Agile estimation.
A key practice of Agile development is the use of whole teams. A whole team is a cross-functional team comprised of between 5-9 people. By cross-functional I mean the team as a whole contains all of the skills needed to accomplish the team’s goals, not that each team member is capable of doing any task. If you have more than 9 people, then you split people up into multiple whole teams.
Planning Poker reminds everybody that the estimate includes all of the work that needs to be accomplished in order for the story to be considered done. It includes development, testing, documentation, and anything else required for the story to be considered done. It is a reminder that nobody on the team gets credit for a job well done until the whole story crosses the finish line. Instead of people saying “well, I finished the development, I don’t know what is taking the tester so long” they are more likely to say “what problem are you running into and how can I help?”
Because user stories are a simple and easy to understand description of the work, user stories allow you to focus on estimating rather than spending lots of time discussing what a particular enhancement request or requirement really is. To maximize the benefits of Planning Poker, you need to be good at creating and using user stories.
In my experience, the best unit to use for estimates is story points. Two different people with two different skill sets or levels of ability in an area may take different amounts of time to perform a particular task. Estimating in hours mixes together the scope of the work that needs to be done with the speed at which a particular individual can do that work.
On the other hand, story points are a relative measure of the scope of a user story. Story points separates out the “what” from the “who.” For instance, if you have one individual that is stronger with .Net than with Java, they will estimate a Java story as taking more hours than somebody that is stronger with Java. But they will probably both agree that something that is twice as easy to implement will take half as long to do.
To use story points, you need to create a relative scale of scope. A simple approach is to find a simple and straightforward story that you use to represent a single story point. Then think of stories that are 2, 3, 5, and 8 times larger in scope. You should have a couple of examples for each story point value to take into account that some stories have more test than coding, more documentation than test, etc.
Story points are primarily used for planning, not for implementation. Story points are used to help determine the contents of an iteration by calculating a velocity.
In Agile, the velocity of a team is simply the number of story points associated with stories that are finished in an iteration. For instance, if the team completed 8 stories that were each 5 points in an iteration, then their velocity for that iteration was 40 story points. In a stable team, a team that is comprised of the same individuals working full time as part of that team, the velocity is a good measure of the overall throughput of the team.
Knowing your velocity helps with planning. For example, if you know that the velocity of your team is 40 points, then you know you can expect 40 story points for each iteration. The team decides which stories to take based on the backlog which is maintained by the product owner.
Regardless of which of these practices you are currently using – whole teams, user stories, story points, velocity – Planning Poker is an excellent tool. The more of these practices you use, the more they reinforce each other and the more value you will get out of Planning Poker. Conversely, the more you use Planning Poker, the more value you will see in implementing all of these practices.
Many of the techniques of Agile development combine together to provide more than the sum of their parts. One technique that definitely fits this description is the Planning Poker method for doing estimation. In part 1 of this post, I will quickly describe the mechanics of Planning Poker. I will then go on to describe how user stories, whole teams, story point estimation, and velocity all work to multiply the value of Planning Poker and how Planning Poker also reinforces the use of and value of the other practices. If you are already familiar with Planning Poker, you may want to skip ahead to “The Five Essential Ingredients of Great Agile Estimation“.
Planning Poker is an estimation technique first described by James Grenning in 2002 in a paper by the same name [pdf]. When I first heard about Planning Poker, I couldn’t help but chuckle. It seemed a bit silly to mix software development and poker. After reading Mike Cohn’s excellent book “Agile Estimating and Planning” I had a good grasp of the mechanics of Planning Poker, but it felt like just a variant of the Delphi method and thus nothing new.
About a year ago we had Kenny Rubin come in to do some Scrum training for us. That was just the shot in the arm that we needed to supercharge Agile adoption at AccuRev. If you are looking for an Agile trainer, I highly recommend Kenny Rubin. It was based on Kenny’s explanation and recommendation that we decided to try Planning Poker on a real project. The results were terrific and after a single session we were hooked. Planning Poker is now a standard part of our Agile process.
In order to play Planning Poker, each participant will need a deck of Planning Poker cards. These are easy to obtain, just Google for “Planning Poker cards” or make your own. You will need the following cards: ½, 1, 2, 3, 5, 8, 13, 20 and a card that indicates “I’ve had enough.” The numbers on the cards represent estimates. You can use story points, ideal days, or some other measure, but in this point I am assuming (and advocating) story points. Typical decks contain cards for much larger numbers than 20, but I think you’ll find that 20 and higher are rarely used once you’ve been using Planning Poker for a year or two.
The whole team gets together for a set amount of time to do story estimation. An hour is usually a good amount of time, but this is completely up to you. When I say “the whole team” I am assuming that you are using small cross-functional teams of 5-9 people (see later parts that discuss the use of whole teams).
Estimation is done on a story-by-story basis in the same order as the backlog, starting with the first story that needs estimating. Somebody reads and describes the story. This is often the product owner, but could be anybody. Some teams do story point estimation without the product owner and just skip stories which they are unable to do without the product owner’s involvement. After the story has been read, participants discuss the story for a bit and then decide on an estimate by picking one of their cards and laying it face down in front of themselves. Once everybody is ready, all of the estimates are shown. If the estimates are all the same, you are done.
Usually, some of the estimates are particularly low or particularly high. A low estimate can indicate that the estimator left something out, or possibly that they know a way to reuse existing work or have some other good information that other folks weren’t aware of. A high estimate may indicate many things, but most commonly it means that the estimator is thinking of something that other folks may not be aware of. For instance, somebody may point out that there is no test framework or tooling for a particular technology and that to adequately test the story the team will need to do a lot of setup work.
In any case, after a round of discussion, everybody chooses a new estimate. This is repeated until the team comes to consensus on the estimate. The estimate is given to the story and then you move on to the next story. You end when you hit the end of the meeting time, you run out of stories to estimate, or somebody plays the “I’ve had enough” card.
One of the biggest benefits of Planning Poker is the sense of team that it creates. The whole team is participating in the estimation. This creates a greater sense of team ownership and team responsibility for each story. Another major benefit of Planning Poker is that you leverage the collective wisdom of the whole team. However, this really only works well when you are using whole teams in the Agile sense of the term.