The estimates are a useful by-product, if your organisation values such things, but actually the most important benefit you get from planning poker is the conversation. As part of the exercise, you explore the story as a team, and uncover any misunderstandings about the scope and depth of the work to be done to satisfy the story. The result of this exploration is a shared understanding of what the story means.

There are other ways to have this same conversation. My favoured practice is to hold a specification workshop where the team explores the scenarios that a user could encounter when using this new functionality. These scenarios are a much more useful product, to me, than an estimate. They give me a starting point for writing my automated acceptance tests, and they also give us all a concrete reference point as to the scope of the story. If my organisation needs estimates to be happy, we can count the number of scenarios to give a realistic feel for the relative size of the story.

If you’re using scrum, you’re probably familiar with using a Release Burndown chart to track the team’s progress, iteration by iteration, towards a bigger goal:

Here we can see the team’s velocity appears to be slowing down. They might still release at the end of Sprint #9, but there’s a chance, if the flattening trend in their velocity continues to worsen, that they may never finish the project at all.

We have enough information here to know that something may be wrong. We can use this information to warn stakeholders that our release date may be at risk of slipping, and may also start looking though the backlog of stories for things we can drop.

The problem with these responses is that they’re purely reactive. Assuming there is a systemic cause at the root of this slow-down, we’re not doing anything to deal with it and get the team back on track. We can go and ask the team what they think might be wrong, and try to help them correct any problems they can identify. This can often work, but sometimes the team may not have the experience or perspective to be able to see what’s going wrong.

Another problem is that we’ve had to wait until the end of the iteration to get this information. For an organisation that’s used to going into the darkness of 9-month waterfall projects, getting iteration velocity figures once a fortnight can see pretty decent. An awful lot can happen inside an iteration though, and having that summed up by a single number loses a lot of important detail. Like the signal on an old short-wave radio, this is low-fidelity data.

One crucial piece of data that’s hidden within the burn-down chart is what I call the rate of discovery. The whole point of agile development is that it’s iterative: we build and ship something, get some feedback, learn from that, build and ship some more, and repeat until our stakeholders are happy with it. If we’re doing iterative (as opposed to repetitive) development, we’re going to discover new user stories as we go through the project, perhaps even as we go through the iteration. This is a good thing: it means we’re listening to our customers. We need to make sure our project plans can handle this as a matter of course.

Going back to our release burn-down, we want to separate the rate of discovery from the rate of delivery. A great way to do this is simply to flip the vertical axis of the chart, and use a Release Burn-Up instead. On here we can start tracking two lines instead of one. First we draw the number of completed stories (or story points), and then stacked on top of that, we draw the number of stories still to do. That includes any story not yet done – whether it’s in the backlog or being worked on in the next iteration.

We can add extra fidelity to this chart in two dimensions: We can collect samples more often, and we can collect details about just how done the stories are as they move from ‘not done’ into ‘done’. Let’s start by collecting more detail about how done the stories are. Imagine our task board looks like this at the end of an iteration:

One story (Story A) is done, and 8 other stories are not done. As we track these counts over time, we can draw one line on our Release Burn Up chart for each category of ‘not done’ and stack the lines:

This chart has another name, Cumulative Flow Diagram (CFD). We call it this because as stories flow from ‘not done’ to ‘done’ across the task board, we’re drawing the accumulation of that flow on the diagram. There are lots of things we can gleam from this diagram.

If we look at the example above, we can see that work is stacking up in the design stage of our process. Because our CFD chart highlights this, we can put more directed effort into relieving the bottleneck on the designers, perhaps by adding an extra analyst to the team to run ahead and do some more detailed analysis of the upcoming stories in the backlog, or by helping the designers to break the existing stories up into smaller ones that are easier to understand.

You can wait until the end of the iteration to count these numbers, but why stay ignorant? If you collect this data every day, you’ll get quick feedback about where bottlenecks are appearing in your team, and be able to try small tweaks to correct them.

There’s also a great transcript of the talk here on Tom Hume’s blog. Thanks Tom!

Back in the pre-agile days when our projects were planned around component pieces of the architecture, “value” was a meaningless concept. The whole project had a value, but day-to-day that didn’t help us prioritise our work – from inside the plan it was impossible to judge whether my database stored procedure was contributing more value than your pricing component – without one, the other would simply not function.

As we started to plan around small deliverables like user stories, the concept of value came to the fore. Suddenly it was obvious that the “file saving” feature was much more valuable than the “conditional formatting” feature. This helped us immensely – we could prioritise our work around this value, and as a result actually felt the glow from knowing that the work we were doing was worthwhile, valuable even.

Now that value has become a first-class concept to software development teams, what happens when it becomes an obsession? When managers who can now measure value and velocity start to compare teams, or offer them incentives to deliver more, faster? When we as developers get so driven and focussed on the delivery of value that we forget to design, refactor, consolidate, reflect, and sharpen our tools? When we forget to go home on time?

We get burned out.

As ever, it’s the responsibility of the developers (and their leaders) to stand firm and hold on to the space and time that they need to do their work at a sustainable pace. Not all the hours you spend in a day – tidying up the build scripts, writing a code generator, cleaning up a library so you can release it as open source – can or should be directly attributed to the value they will immediately offer to the business. That’s not to say we should spend our days idling, but that we should maintain a level of self-respect in everything that we do.

So far, so good. Where could it possibly go wrong?

One thing you may miss here, is how long changing ‘potentially shippable’ into ‘actually shipped’ might take. Building code and deploying it to a system test or user test environment where the business users can play with your changes might feel potentially shippable, but in the cold hard light of day, it still may be far from truly shippable, let alone shipped the fuck out. At this stage, the work you have done may seem to have some limited value to your customer in that they may poke around in it to help validate the work you’re doing, but until the day they can actually start using it to make their lives happier and more productive, that value is negligible.

You may choose to put stories into your backlog to cover off deliverables like ‘Deploy to Live Environment’, and ‘Hardening Sprint’ but these are high risk stories whose delivery tasks are very different to normal development work, and hence their velocity is hard to predict. Danger lurks here.

Better to make deployment to your live environment (or if that’s not possible, something very similar to it) part of your definition of ‘done’. If you decide to start doing this half way through your project, embrace your plummeting velocity, for it is your true velocity, and it is much less likely to make wildly optimistic predictions about your schedule.

With our second major live release looming large on the horizon, I focussed the session on the theme of ‘Success’. My aim was to give the team a blueprint for a successful iteration to keep in mind when things were tough, and to help ensure that we were all pulling in the same direction by agreeing as a team what constitutes success for us.

I started by asking the team to score how successful, in their own mind, the last iteration had been, drawing a histogram on the flipchart of the results. Interestingly, there was quite a variance in the scores, with most people either grading the iteration 2/5 or 4/5, perhaps suggesting that different members of the team have different criteria for success, or that they just experienced the iteration differently.

I then asked them to reflect on the criteria they’d used to make that judgement, again in their own mind, capturing each of the criteria on a separate index card. We then spread the cards out on the floor, and mapped them into headings: teamwork, stability, delivery, happiness & joy… and a couple of others I can’t remember right now.

We then decided that our output would be some kind of vision statement under each heading, of the form “An iteration is a success when…” and worked through the various headings, discussing what it was that made us successful, and distilling that discussion into a bullet point on the chart.

Reflecting on what we’d covered, it seems to me that while the session was fun, motivating and affirming for the team, and thus valuable in it’s own way, it didn’t really enable us to focus on the major issues that are affecting us right now, such as the disruption of the recent office move. It also didn’t leave us with any concrete actions to take away and do in order to make things better. In terms of inspect and adapt, it really didn’t deliver.

When planning your retrospectives always remember your key goals (in priority order):

1. Try to smoke out the most significant areas of waste in the team’s production of quality software
2. Invent concrete actions you can take in order to reduce this waste
3. Build and motivate the team

Whilst building and motivating the team is an important goal for a session like this, it’s often a side-effect of successfully satisfying the first two. Concentrate on facilitating a session that helps reduce waste while having fun, and you’ve hit the nail on the head.

One of my key questions about Kanban is how it’s possible to predict long-term delivery dates for specific features, and although Karl goes some way to answering those questions, it looks as though you need, as well as a mature agile team, a fairly mature and trusting organisation to make this work.

I guess you also need to be working on a product that’s already in production and being updated regularly.

Well, so the received wisdom goes, by comparing how long it took you to complete your a task against the estimate you made before starting it, you get an idea of how good your estimate was. So far, so good.

But what if your estimate turned out to be wrong? What are you going to do about that?

One of the culture shocks I think scrum introduces it the idea that we almost always just look forward. I don’t care how long you’ve spent on a task, I just want to know how long you think it will take you to finish it, based on what you know right now.

Tomorrow, if you turned out to be wrong, that’s OK. All we need to know is how much longer it’s going to take to get it done.

Except it’s not OK.

Because if your task, which you originally estimated would take 2 hours has taken you two days, and it’s still not done, then something is impeding you.

Fortunately in a team practicing scrum, we have a daily 15-minute meeting where impediments like this are made visible to the entire team, and someone takes away the action to resolve the impediment.

Rather than having to retrospectively scan reports of esimates vs actuals in a spreadsheet, the problem can be highlighted as it’s happening, and hopefully resolved.

Agile teams also have a second line of defence against more stubborn impediments: The retrospective.

With these two facilities in place, it becomes unnecesary to track the details of estimates vs actuals. The administrative overhead on developers is reduced, and they can get back to writing solid code.

Some people find this difficult to accept – there’s a familiarity to the recording of the numbers. We’ve allways done it. It makes me feel safe. Somebody will ask us for them.

If someobody asks you how good your estimating is – show them your burn-down chart.

It’s bloody obvious from the shape of the chart if your estimating is any good. And if they want figures, measure the difference in area beneath your real curve (blue line) and your ‘ideal’ diagonal curve (red line). Every hour above the diagnoal line is an under-estimated hour. Show this to your team. Get them to look at it and reflect on how realistic they’re being when they estimate tasks.

If somebody asks you why your estimates were too low – listen to people. Look at your impediments log, and the write-up of your retrospectives. You need a culture where impediments get surfaced quickly from the team, where it’s OK to say things aren’t going well, and where problems raised get solved and cleared out of the way.

So, like all good self-organising teams, we got together and talked about it. Yep, we had a meeting about a meeting.

During this, at times heated, discussion it became clear that we were talking about two separate issues. As well as using the stand-up to synchronise our work, we were using it as our starting-point for the day. Those who like a lie-in will tend to get themselves in just in time for stand-up, and thus their day begins.

So while the first and most obvious issue for debate was what time to have the stand-up meeting, lurking in the background was the much more thorny issue of how late it is acceptable for a team-member to turn up for work.

Fortunately we spotted this pretty much in time before the mud-slinging between the early-risers and the alarm-clock-o-phobes began. On reflection of the benefits of the meeting as a whole, we judged that providing a start-point for the day was not as important as the other benefits about communication which require every member of the team to be present. So we decided to abandon the use of the stand-up as our start to the day.

So that we can still harness the motivation that comes out of a good stand-up, we decided to hold it at 2pm, when everyone should be back from lunch and ready to blast through the afternoon.

All we can do is try it and see how it works.

What time do your team have their stand-up, and why?

It’s something I’ve been giving some thought to lately. I coach my team informally on a daily basis as we work together and more formally at the end of each iteration during our retrospective. I’ve also been asked to start a process of coaching other teams too.

In my other life, I teach people to snowboard. BASI, the organisation who taught me to teach, have developed a clear progression from complete novice through experienced recreational riders, right up to instructor trainer. Similarly, I just took the PADI Open Water Diver course, and again there is a clear progression where you learn the skills required to dive safely on your own.

Like Raganwald, I feel that certifying people for technical skills like expertise in coding a particular language is really missing the point. I thing he’s on to something by wanting to prove that a person knows how to produce a bullet-proof product – after all, that’s the whole point isn’t it?

I’m interested in the series of learnings that people go though in their time at work that take them to the point where they do a lot of these things as second nature. Where they don’t claim something is ‘finished’ when they first manage to get some data up on the screen; where they know exactly when to step away from the keyboard and make a cup of tea to mull something over, or when to ask for some help instead of thrashing themselves, quietly, into a rotting hole. The things that make people valued members of my team are much more the ‘soft’ skills that mean they spend their time at work as effectively as possible, like confidence, humility, and empathy.

In a way it’s a good thing that we don’t just have a simple scale to measure people against, we’re dealing with real human beings, after all. On the other hand, it might be handy to have a map to help us all along the way.