One of the most exciting (and challenging) aspects of being agile is planning user stories. They should bring small packages of customer value, yet be well-described for developers and also have acceptance criteria for testing. Sometimes easier said than done!

Pain points

Over the years, our team has got quite good at defining user stories that are visible and value-bringing for the customer. We've even got good at making them nice and "thin" so that we can see progress quickly and aren't dependent on everything being ready to make it worthwhile. Nevertheless, like every team, we have our pain points. For us these are most often forgetting details (what needs to be tested, what aspects of the development can't be forgotten when implementing this story, etc.) We also sometimes found it difficult to see whether everything was going to plan in terms of time or not. This was often compounded by "sneaky stories" joining the sprint after it had started, essentially increasing what we had to do in the same amount of time. (An entry on why sneaky stories are dangerous anyway is here).

Throwing out the board

About three sprints ago, we decided to change some fundamentals of how we were doing things. Up until then, we'd been using a storyboard.

On the one hand, this was nice and easy to use and it was very visual. However, there were some aspects of our process for which it wasn't supporting us, and some aspects in which it was helping us to be bad...

The board was a bad influence

First of all, cards are just so temptingly easy to add to the storyboard once the sprint has started. There was no automated collection of how many story points we had planned, no way of seeing that this had happened, and no way of seeing how often within a sprint. Also, if you know you can change things, maybe you don't plan so well in the first place.

Lack of details

The cards themselves were also problematic. They let us write nice user-stories, but never really had enough room to write individual development activities (update model, show new info in problems view, documentation etc), or acceptance criteria. Details sometimes got left out, sometimes forgotten. At the same time, we had no good way of managing a product backlog where we could always go back and see what we'd already planned, what we'd estimated and what other things are of interest.

On a purely logistical level, our wall was also getting too small for a growing team.

Time for a tool?

So, three sprints ago, we decided to try out a tool we use at the company for other aspects of our work (booking hours, calendars, project planning, writing invoices etc) which proclaimed to have support for agile processes. We were naturally somewhat sceptical, because we thought that it would limit us in our work. Nevertheless, one of the great things about agile teams is their willingness and ability to try out new things, so we launched a pilot sprint for the tool.

Three sprints on, and we're actually really enjoying it and gaining benefits from specific areas of additional structure it brings us.

Hierarchy: from story to technical details

First of all, epics, stories and activities are created and edited as hierarchical structures. We can keep the customer perspective we've got so good at thinking of while also specifying more technical activities for the developer, so our stories are more well-rounded and also well-estimated. Because everything we've done gets saved into the backlog, we don't have to do any work twice. If we've discussed a feature, written partial or complete stories for it, done mock-ups etc, then those data are still all there later. We can use old stories to help us plan new ones, and we can go back to not-yet-fully-planned stories and carry on where we left off - even if it was a while ago because something else got prioritized instead.

Prioritization

Speaking of prioritization, that's become easier too. Without a well-maintained central list of what the customers want (we have multiple sources for requirements), then it's easy to prioritize something more highly for an upcoming sprint and forget that other things are maybe just as (if not more) important. Now, we see exactly what we're leaving out to include something else and can make sure that that's a decision the customer(s) want(s) to make.

Keeps us on the straight and narrow

At the beginning of the sprint, we add product backlog items to the sprint backlog in the tool. Once the sprint has started, it's very much a "holy" object. An automatic burn-down chart gets created every day, and we have a representation of our old story board on our screens. It is "difficult" to add new items to the sprint, and impossible to do so without noticing that our planned story points have increased. So we don't do it. This has advantages for our transparency with our customers as well - we can tell them exactly when a sprint is beginning, and exactly what it will contain.

Tool must support the team

Now, working with the tool wasn't the only change we made - we also started doing more regular, but shorter, planning meetings and changing the way we work with known or new issues within a sprint. So our general planning has changed a bit too, but even here its nice to know that the results of our planning are safe in the backlog, with all the information it contains.

I wouldn't want to say by any stretch of the imagination that the tool is perfect, or even that our way of working with it is always ideal. Nor would I want to challenge the idea that tools are secondary to interaction. But used in the right way, a tool can help a team to improve. We've now had three good consecutive sprints, and that's worth celebrating .