Answering “Are We on Track?” With a Burndown Chart

January 10, 2013 by Leave a Comment
Recently, on twitter, Tobias Mayer asked if anyone was still using burndown charts as described in the original scrum literature:
I personally enjoy using burndown charts and like exploring the different stories they can tell given the multitude of ways you can design them. I am currently working with a team that is using a commitment driven approach to planning who also uses a burndown chart of remaining task hours. I replied to Tobias with:
 

This seemed to spark a big discussion with a lot of people chiming in with their opinions and experiences. The discussion followed the usual Agile Twitter Debate Formula™ involving charges of not being agile, assuming mutual exclusivity with other practices, general misinterpretations of various points concluding with the usual series of just-do-what-you-want-and-lets-stop-arguing-about-this tweets.

Since twitter proves time and again to be a terrible place to expand on things, I figured it was worth explaining my original tweet in a little more detail here.

Value vs. Work

One of the first issues that came up in this discussion was that the sum of tasks for a particular user story don’t necessarily add up to any real meaningful value, so since tasks themselves don’t represent value, we shouldn’t be tracking them.
 

So, fair enough, tasks don’t represent value so let’s track story points instead. While I think that a burndown chart of story points can tell a story, I like to tell lots of stories so I usually use this in conjunction with other artifacts. I’ve also seen plenty of teams who have a burndown chart of story points that goes sideways for three days and then everyone realizes that they’re not going to get everything done by the end of the sprint. Whoops!

Do we have enough gas to get there?

Imagine that you and some friends are planning a road trip to an outdoor music festival. You all hop in the car and get going. Being a beautiful day, you suggest taking the scenic route and stopping on the way to take a group photo. As you’re driving, the GPS on your dashboard is squawking commands and you’re fairly confident that you’re heading in the right direction. After a few hours someone in the backseat asks “Hey, do we need to stop and get gas?”

At that moment you look down and realize that you’ve got a quarter tank left, with some quick math and a glance at the GPS you determine that you do not have quite enough gas to make it to the music festival and having passed the last gas station before your destination you can’t stop and get more. Your only choice is to break the bad news to your friends and negotiate taking the group photo on the way back from the music festival.

Are We on Track?

I view a burndown chart of hours remaining as a gas gauge. It doesn’t tell us anything about if we’re going in the right direction or if we’ll ultimately get to our destination, but it can be a useful way of making sure that you’ve got what it takes to make it there.

Most importantly, tracking hours remaining isn’t about tracking hours, or management making sure people are busy or any of the other treacherous things suggested during this twitter discussion. For me, tracking hours remaining is about all of the questions and things you uncover as a result of asking “Are we on track?” and the answer that follows.

Filed Under: Agile Tagged With: , , ,

Add Some Fun to Your Scrum Board

May 3, 2012 by Leave a Comment

Physical Boards Please

I recently started working with a team who had been introduced to scrum as part of their organization’s adoption of agile. Their only experience with scrum was through the lens of a popular agile project management tool that rhymes with alley, as in “After using this software I want to vomit in an alley”. When they had the chance to use a physical board, they jumped on it. I setup a very simple scrum board on the outside of a cubicle near the team. We used index cards and colored pushpins, the normal stuff. After a few days, the team was loving it. They enjoyed moving tasks around, pushing green pins into completed cards and keeping an eye on which tasks were in-progress.

Accidental WIP

That’s when I noticed something strange. When I setup the board, out of sheer laziness on my part (I kept pricking my finger reaching into the bag of push pins) I only provided them with three yellow pins and three red pins, one for each member of the team. In doing so, I had created this artificial WIP limit. The team treated the yellow and red pins as their “own” as in, “this is my yellow pin”. At first I just though this was a neat little side effect of the circumstances, but then I realized I could capitalize on the situation by adding some personality to the board.

The last time you played Monopoly™, the board game, did anyone make a big deal about choosing their token? I bet they did, that seems to happen every time I play. There’s always the guy who has to be the race car or the top hat or whatever. People are serious about their monopoly pieces.

So back to the scrum board. I wondered to myself, could I somehow affix monopoly pieces to these push pins? With a quick trip to eBay for a bag of random monopoly pieces and some super glue, I had the answer. Yes, it can be done.

I presented the idea to the team and let them know that if they wanted to use a special push pin they could, or if they’d like to use a regular one that was fine too. The initial reaction was all smiles, quickly followed by, “I’m gonna go first before anyone else picks the race car!”

Filed Under: Agile, Ideas, Scrum Tagged With: , , , ,

Retrospectives: Best Practices, Common Problems and New Ideas

May 2, 2012 by Leave a Comment

Here are the slides for my presentation at the May 2012 Phoenix Scrum User’s Group meeting. If you attended the meeting and have any further questions, please contact me, clayton@integrumtech.com.

Retrospectives: Best Practices, Common Problems and New Ideas
Filed Under: Agile, Scrum Tagged With: , , ,

Probability, Velocity and Re-Estimating User Stories

July 6, 2011 by 2 Comments

When working with user stories, story points and SCRUM, it is not uncommon to come to the end of a sprint and realize that a smaller story took longer to complete than a larger story. While this is an excellent reminder that story points reflect complexity, not effort, it is often misinterpreted as an indication that remaining stories need to be re-estimated. Basic probability distribution shows us that over a large enough sample, all three point stories in the product backlog will take about the same time to complete. A team’s desire to re-estimate stories in the product backlog based on a few stories deviating from the norm is a mistake.

Not All Stories are Created Equal

If you were to roll a pair of dice a million times, you would see the majority rolls sum up to seven. If you graphed the data, you would see a bell curve shape. User stories are no different.

Over a large enough sample, you will start to see the same bell curve shape in the time it took to complete those stories. Some three point stories might take two hours to complete while others take twelve; but most take seven. At the same time, some of your five point stories will take ten hours to complete and some twenty four; but most take eighteen. Consider the overlap in the following diagram:

The overlap between the time to complete some of the three point stories and some of the five point stories should not be mistaken for a need to re-estimate any stories. Sometimes a three point story will take as long to complete as a five point story.

Commitment Driven Planning

One technique from which all SCRUM teams could benefit is that of Commitment Driven Planning. From Cohn’s Agile Estimating and Planning

A commitment-driven approach is an alternative way to plan an iteration. Commitment-driven iteration planning involves many of the same steps as velocity-driven iteration planning. However, rather than creating an iteration plan that uses the yesterday’s weather idea to determine how many story points or ideal days should be planned into the current iteration, the team is asked to add stories to the iteration one by one until they can commit to completing no more.

So what happens when a three point story is tasked out and comes to ten hours, and a five point story is tasked out and comes to nine? Often times the first inclination of the team is to inflate the three point story. Especially interesting is that almost no one suggests to shrink the estimate of the five point story. Again, we should expect that some three point stories will take the same amount of time to complete as some five point stories, but in the end this will even out.

Velocity is The Great Equalizer

Again from Mike Cohn’s Agile Estimating and Planning

What’s happened here is that velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. We cannot simply roll a die and assign that number as the estimate to a feature. However, as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule.

As the team complete more and more sprints, developers will come across three point stories that are a little larger than average and five point stories that are a little smaller than average. Between our bell curve distributions and velocity acting as the great equalizer, over time, the bumps in the estimations will smooth out and the desire to re-estimate stories will fade.

Filed Under: Agile, Scrum Tagged With: , , ,

Agile Principles: Deliver Early and Often, but Always Deliver Value

June 17, 2011 by Leave a Comment

The Agile Manifesto describes twelve principles of agile software. In a series of twelve blog posts, I will explore each principle.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

This principle can be broken down into two separate thoughts. Continuously delivering early, and always delivering value.

Delivering Early and Often

Delivering early is more than just delivering something before the competition. Delivering early is more than just delivering before you would have had you not been being Agile™. Delivering early means specifically delivering less than you could have otherwise. Continuous delivery and iterative development are synonymous, it is not enough to just deliver early, you need to frequently do so.

Always Deliver Value

Delivering value is difficult. At a high level, it is difficult to know what is and is not valuable. Following the process and being disciplined can get you to a point where you are delivering early and often, but without a unified vision of what you are creating, it is very difficult to deliver real value.

Delivery early and often, but always deliver something of value.

Filed Under: Agile, Scrum Tagged With: , ,

Let Conversations Write Your Tests

May 10, 2011 by 2 Comments

I consider myself an early adopter of Cucumber and have spent a lot of time using, thinking about, writing about and discussing cucumber and, at a higher level, behavioral driven development. Lately however, I’ve really been rethinking how I use Cucumber and why. Am I getting enough benefit from the overhead and abstraction of plain text features? Could I do the same thing with RSpec if I just approached RSpec differently? Am I cuking it wrong?

This shift in thinking is due in part to Liz Keogh’s Step Away from the Tools and Dan North’s Who’s domain is it anyway?. Both of these got me thinking about how I’m using the term BDD (rather loosely) and how much of an investment I’m making in a specific tool (Cucumber).

More Meaningful Planning

Having meaningful planning meetings with their customer/product owner is one thing with which many teams struggle. Too often, we go too fast, don’t uncover enough detail, use the wrong language, don’t understand “done” and leave too many loose ends.

To combat this we draw screens, discuss workflows, ask leading questions and a variety of other techniques. I felt that while I was doing these things, I was still frustrated with the other part of the planning process. I’ve never liked traditional tasking and I’ve never like the idea of having to translate all of the data gathered with the customer into some other form only to express it later in a test in yet another form.

What if I wrote my tests during the planning meeting?

I decided that changing the way I gathered conditions of satisfaction, defined “done” and discussed workflows with my product owner would give me the biggest boost in value delivered, so one day I did just that.

For the following examples, assume that we’re adding a feature to an e-commerce website.

As a user I should be able to manage addresses so that I don’t have to enter my information more than once

As I’m discussing the feature with my product owner, I will discuss with them the possible scenarios, including workflows, required to use the feature. Some scenarios for this feature might include:

  • When I am on my account page
  • When I am creating a new address
  • When I am deleting an address

These scenarios might have scenarios of their own:

  • When I am editing an address
    • When I successfully edit my address
    • When editing my address fails

So far I’ve been able to ask the product owner something like “So when I’m editing my address, and I miss some required fields, what happens? What do I see? Where do I go? What are the required fields?”. I can also draw pictures to explain the workflows and ask more questions “What’s on this page? Where is the error message displayed? Do I see error messages for the fields that are missing?”.

For each scenario, I can capture assertions that come from answers to the questions I’m asking:

  • When I am on my account page
    • I should see a link to “My Addresses”
  • When I click on the “My Addresses” link from my account page
    • I should be on my addresses page
    • I should see “My Addresses” in the page heading
  • When I am on my addresses page
    • When I have existing addresses
      • I should see each address listed in format xyz
      • I should see an “edit” link for each address listed
    • When I don’t have existing addresses
      • I should see help text explaining how to add an address

If you’re an RSpec user, you might be thinking, “Hey this looks like RSpec!” and it does. During the planning meeting I can capture these scenarios and outcomes and then use them nearly verbatim for my RSpec acceptance tests. Even better, when I run my tests, I can use the “documentation” format that RSpec gives you to output that’s almost identical to the scenarios above.

The conversation required to really define these scenarios and outcomes is challenging, but at the same time, very rewarding. I have also found that it’s pretty powerful to be able to sit with the product owner and view two nearly identical documents side-by-side knowing that one is automated test output.

Filed Under: Ideas, Ruby On Rails, Testing Tagged With: , , , ,