When you should change the done state from accepted to something else

The states in Pivotal Tracker can mean different things to different teams.

Typically, the finished state means developers have finished coding a story and have run their standard tests. The story is then delivered when it's ready for acceptance testing (deployed to a staging environment perhaps). If the acceptance test is conclusive, the story can be accepted. That's usually done by the client or product owner. In most cases, if a story is accepted, it means the criteria for the definition of done (DoD) have been met.

That's just one way of working, though. In some teams, developers set a story to finish, deploy it in a staging environment (or it gets done automatically), and then move on to work on something else while waiting for it to be accepted. The problem with that way of working is that sometimes the person responsible for accepting a story doesn't do so before the end of the iteration.

Although teams who work that way usually admit it's not ideal, it's the process they have in place for now. If that sounds like your team, not to worry. There are ways for you to improve the way you work without doing a complete overhaul.

The eleventh-hour approach

If your team does acceptance testing on the last day and your stories get approved most of the time, your team probably has a good definition of done. Your developers likely know exactly what standards are expected and are able to meet them.

That's great, but now imagine drawing a burndown chart of one of your iterations. It would show a flat horizontal line for 90% of the iteration and then 0 points left on the last day. The process renders a burndown chart based on the accepted state essentially useless.

Luckily, Insight offers a way to select a done state for each one of your boards. Enabling this is just a matter of selecting the done state between finished, delivered and accepted in the board configuration. This option makes it possible for you to have a meaningful burndown chart even if you're dependent on external factors for acceptance.

What about declined stories?

It can be problematic when stories that have been awaiting acceptance for a while get rejected on the last day of an iteration. You're faced with a choice: move the stories to the next iteration, or get your developers on a last-minute rush to fix what needs to be fixed.

Moving rejected stories to the next iteration is fine once, but it's easy to see how it could become a problem if it happens repeatedly.

In you opt for last-minute rush, your developers need to wrap their heads around the story (all over again) before fixing and delivering it (all over again). And since they were most likely working on something else when the story got rejected, the interruption will come at a cost. Not to mention that when they do finally go back to working on that something else, they'll have to wrap their heads around that story all over again. It's not hard to see how the whole back and forth process can become quite expensive.

For all those reasons, aim for the QA process to be done as often as possible and the feedback loop to be as short as possible.

Having said that, if your team isn't yet able to accept stories as they get delivered, or if you depend on a third party to accept them, try changing the done state to something else. That will let you to continue measuring the rest of your process while ignoring the parts you can't control.