We used to be very much of the mindset that each story had one person working on it at a time. Often people would say, oh I don’t think you can get more than one person down that hole. This leads to problems.

Large stories that would take a single person more than a sprint to complete are not uncommon for us. Partly because we’re not (yet) that good at breaking stories down and I suspect partly due to the legacy code we are working with. Anyway if we only have one person working on such a story they aren’t going to get finished inside a sprint, so it’s hard to track progress which can hide big problems for too long.

One of the ways I’ve tired to help people change their mind about the one-person per story mindset is to task up stories at the beginning of a sprint like normal. Then we position the tasks to highlight parallel streams of work. So if two tasks can be done at the same time they sit on post-it notes on the same line. It’s not uncommon for there to be 3 or even 4 possible streams of development for at least part of the sprint.

Related to this is that tasks that are ‘stalling’ (taking longer than expected) can also be split once they are identified. If you identify a task that is taking longer than a day then ask what’s going on, what work is being done, what’s still left. I ask people to write their responses up as additional tasks in the same way as in the sprint planning. We can then split up these tasks amongst the rest of the team if need be and have a better chance of getting to done.

I’m sure the real solution is to get rid of the big stories, but until we acquire that skill (we’re working on it!), this process seems to be working well for us.

I tried this exercise from Jurgen Appelo in one of our weekly team time slots. You get 10 cards each with a different intrinsic motivator on them. In the first step you simply order them from most to least important. Sounds easy, but almost everyone has one or two they  struggle to place, either because they find it hard to define (honour was a particular problem for my team) or because they value them similarly.

Continue reading →

So I went on the course that goes with the book and I had a great time. It was Jurgen Appelo himself who did our class so it was good to meet him and he is a really interesting and engaging person. Despite having a horrible cold I didn’t find myself drifting off or losing track.

Over the next few days I’m going to write about a few of the ideas from the course that resonated with me. The first of these is slack time.

This is something that I didn’t immediately think of when asked about takeaways, but it’s something that’s been growing on me for the past day or so.

In our team we’re definitely guilty of not leaving any slack, the temptation is to fill up the sprints as full as possible, often with a bit extra thrown in for good measure. This leads to a relentless pace with us often feeling demotivated because we can’t get everything we planned done. As scrum master I’ve tried in the past to tone things down, asked the team to put less in, but in the end I fall into the same trap of just wanting to get everything done and keep the sponsors happy.

Looking back over the last release I’m starting to realise that this is not working well and we need to change. We need occasions where we can sit back and congratulate ourselves about finishing everything we planned. We need to feel good about ourselves now and then or it doesn’t take long before you lose your energy and then you end up working even slower. There are other bad effects as well, the crammed sprints mean that our testers fall behind and never quite catch-up which means we end up with a mini-waterfall rather than agile.

The problem is that on a 3 month release cycle it doesn’t feel like we have the time to experiment. If we plan in a really ‘light’ sprint with few features how are we going to meet the sponsors expectations, it can look (and feel) like we are just slacking off. There isn’t time for things to even out, or at least that’s the way it feels.

We need to find a way to break out of this cycle and to change the way we work, we need to manage expectations of sponsors so that we have the space to make these changes and we have to convince them that it will benefit them in the long run as well.