Comments on jogobom: Tell me a story

What you're already doing sounds pretty good to me...

2006-02-12T20:54:15.920Z

What you're already doing sounds pretty good to me, Chris. And if it works, well, you know the rest.

For me, the big thing about stories is that they get at the *requirements*. Comparing them to writing specs simply isn't valid, IMHO. Requirements and specifications are two very different things. Stories simply address the requirements in a very simple form.

Regarding the format of the stories, I've heard some debate about this lately. In my last job, a single sentence of the following form was espoused:

"As a [role], I want to be able to [perform some action] so that I [get some benefit]."

The three things in square brackets are all you really need for a good requirement: knowledge of which stakeholder it's for; knowledge of what their goal/need; knowledge of how it benefits them. Knowledge of the benefit, in particular, gives a great insight to their work and the priority of the requirement.

That, for me, is the power of stories. By aiming to record those essential bits of domain analysis, it forces you to look into requirements from a goal point of view. Or, at least, it should. :)

Of course I knew it was a joke, hence the "irony a...

2006-02-08T19:56:51.316Z

Of course I knew it was a joke, hence the "irony alert!" tooltip on the link. Give me some credit man! ;-)

As for using waterfall, well, that was just an example. I don't know if what we do has a name, it's just what we do. For the sake of argument, I'll call it "The Chris & Pete Model", since it's what me and Pete have come round to doing in the last couple of years.

We have 5 permanent developers working for us on our tools team. Each one is responsible for a particular area (e.g. level building tools). That person drives the development of those tools. When major work needs doing, they liaise with the customers and me and Pete to produce a feasibility document listing the requirements in reasonably basic form. It also includes a basic architecture showing how they intend to develop software to meet those requirements. Me and Pete sign off on that (acting in the place of the customer) and they go ahead and develop a more complete design that is sufficient to explain to me and Pete what work they need to do and that we can be reasonably sure it is going to be well structured, extensible, reusable, that they've thought about error handling fully and so on. Pete and I sign off on that too, again acting as the customer. But we are also customers in another sense, since it is our larger codebase that the developed features need to integrate with and that's a big part of my job - from technical, reuse and integration standpoints, will the developed software be good enough? Then the various steps involved in implementing that design are estimated and entered into the project plan and implementation begins.

Each person on the team does this for their particular area and Pete and I spend a lot of our time making sure all the different ongoing developments fit together and meet the needs of the customers.

The system has many benefits. Each person becomes a domain expert on their particular area, with me as the person who has the broad knowledge of a bit of every area. It also means that anybody who has a problem with a particular tool knows exactly which person to go to and ask about it - our customers have a name and a face that they know they can go to who will care about what they are saying. There are other benefits and no doubt a great many costs as well.

I think in any system that was story-driven then me and Pete would end up being the people writing the stories, so I guess in that sense we would have as much chance of getting them correct as we have now. I sort of feel that it would take some ownership away from the team members, who currently get to champion their particular area. I know we'd get collective ownership out of it and maybe that's not a bad thing...

I don't know, it seems like there's some good stuff that I should be taking on board but it's hard to see quite where it fits in.

First of all - you did realise that the Waterfall ...

2006-02-08T07:03:12.293Z

First of all - you did realise that the Waterfall conference page was a joke, didn't you?

As for writing and selecting stories - yeah, it's hard. I think think it's easier than writing a spec though - in a spec you need to know exactly how everything will work, with stories you just need to know what they achieve.

Now - managing multiple projects is a whole different kettle of worms. Your example is going to be very difficult to work in real life - you have one big tools team working simultaneously on different tools for different platforms, presumably with different people "owning" them? First of all, don't forget that you're running fairly short iterations (1-6 weeks, depending on preference and methodology...) and you have all the people responsible for prioritisation in the room at the same time at the start of the iteration. It's THEIR responsibility to debate and determine the relative priority of the different tools and to manage the cross team relationships at their level. What I personally would do would be to have a separate release burn-down for each product, so they can see how each one is doing at these meetings.

Now, within an iteration, you don't have a problem, even in your example. Neither of these stories is of higher priority - you get them both done in the iteration and that's all there is to it, so it doesn't matter which order you do them in.

For me, one of the main strengths of agile techniques isn't that you finish sooner or have higher quality (although they are
*generally * true), it's that you have much better visibility of what's going on - you can *see* that your XBox module is suffering in favour of the PS2 module early on and decide what to do about it.
In other words, I think that even in your example it will be easier to predict an accurate release date using agile methods - that doesn't mean the release date is going to be one that management will like...!

I have to get dressed and go to work now - hope I've made sense!

But just out of interest Chris - can you tell me how you would handle the situation you described using waterfall? To me, it seems like it would be even worse!