First steps

We now have User Stories, yeah!

Very interesting and a different way of getting things done.

I think I must have unconsciously taken on the role of coach for this organisation, which makes sense, but surprised me a bit when it dawned on me. I've never done anything like this before, but I've got the motivation and a grasp of what we should be doing, so my job is to keep things on track, i.e. be the coach.

Anyway, we had a planning session yesterday afternoon. 2 developers and 1 customer. A bit of a substitute customer (for an internal project), but a customer all the same. We walked out with 30 story cards. In my naivety and wanting to tackle things in small bites, we (the developers) didn't do any estimations with the stories, though we did ask questions and tried to break up general stories into stories that we felt we could then estimate.

This morning we set about giving these stories estimates. I started quickly on my own just dividing the stories into 4 separate groups. Then we sat down and started estimating. My initial feeling about the first group, the easiest to do, were about spot on. I was off on everything else. 8)

In the end, sitting down and thinking about the stories with another developer, we started to pull out the simplicity of the stories. We found that some were about state, some were about security and access, some were about functionality and some were about user interface. And finding these categories help enormously in finding the heart of the task and estimating that task.

Basically we had 1's which we saw as the simple things. There were fat 1's and skinny 1's, but in the end they were all ones. Same with the 2's, with one more 2 than 1's. And a couple of 3's. My feeling is that each story is one ideal day, but I've shied about from saying day or any time description on these numbers around anyone that isn't a developer. I don't need expectations just yet from outside of the team.

Ah, but the real reason for wanting to post this: seeing a "mistake" and learning from it. As I said before, we didn't estimate during the discussion with the customer. In categorizing stories, we actually found a few holes in the stories. If we would have been doing this with the customer, then we would have prompted for the need of these stories. Being an internal project, we just wrote them ourselves (but verified them with the customer later, to which the response was "D'oh, how'd we miss that! 8)").

I immediately pointed this out to the team (i.e. the other developer...) which sparked a bit of a discussion. His point being that with an onsite customer, not getting all the stories at the time we had the meeting wasn't a bad thing, because they would have come up later and we'd just go talk to the customer then and there.

My point was, yes, from a "make sure you get the full specifications" I'd agree, but there is another thing happening in the meeting, and that is allowing the customer to plan the iteration. Without the estimates they aren't going to be doing it anyway, but if we haven't flushed out all the stories, they are missing an opportunity to plan for the value in the stories, if needed. On retrospect, this point seems very moot, because they wouldn't be planning without the estimations anyway. BUT, it did illuminate how some of the priniciples do work together.

It's all very exciting, but it is moving very slow. It's all new practices and hence we still seem to have training wheels on, but I'm getting to grips with what to do and how it feels. NICE 8)