How to write stories _before_ the project kicks off

Recently, I was coaching a client who was embarking on a new project. The project team was not formed, but key stakeholders were planning what the projected needed to be. In Agile (specifically our Lean/Scrum/XP mix), we have iteration planning, release planning, and project planning. This client is doing project planning, and the question came up about how to write stories for the project. After all, we have to know the entire scope of the project in order to plan it, right? Historical trends tell us that even if we think we know the full scope of the project, we’ll be wrong, so I helped this client identify the key components of the project to formulate the high-level project scope.

If you like this post, you can subscribe to my feed at http://feeds.feedburner.com/jeffreypalermo

After we understood what the high-level requirements of the new software would be, we did a prioritization and created a backlog that we hoped would turn into a short-term first release. With this rough release plan in mind, we did a small story-writing workshop. We first wrote some stories together and then broke off into pairs to complete the remaining stories. We concentrated on only the first release because that release contained the highest priority items (from the prioritized backlog). We knew we were working on the highest value items first.

Here is an example of a story (adapted from CodeCampServer as a realistic example):

"As an organizer I want to have a place to enter maps and driving
directions so that the attendees can find the event."

First, we have the persona of the organizer. The organizer is in charge of the event and is doing the planning. Often it’s helpful to give him a name. We’ll call him Oscar the organizer. Then, we can discuss what Oscar cares about to get a feel for how he’ll use the system.

Your first thought is that this isn’t enough detail to formulate a release plan, and you’re right, but it’s a placeholder for a conversation with the team that’s going to make it happen. I think a requirements document is also necessary. Writing stories doesn’t take away the need to think about some level of detail while planning the overall project. After all, when estimating the release, it’s necessary to know if driving directions merely means a link to Google Maps or if it means an interactive mapping system built into the application.

Be careful about adding too much detail to the story because then people won’t read it. If every story is a full page, it’s too long. Story can act as headers in a requirements document, however, if you prefer to organize it that way.

Ok, buddy, but how will we know what the acceptance conditions are? You need to know the high-level acceptance conditions, but I caution against laboring too much on small details of each story before the project has even kicked off. You’ll paralyze yourself with analysis. Define just enough detail to move to the next step, release planning. By the time you move through iteration planning, and the team has asked all their questions, all the details will be fleshed out, and the team can turn the story into working software.

Finally, get help from someone with Agile experience. I’ve seen many people who have studies Lean/Scrum/XP struggle to move from use cases to stories with only academic knowledge. There is no replacement for apprenticeship.

Eleasar 4:06 pm on January 24, 2008

Hi,
what I always wonder is: how do you charge the customer for the project? I also love the approach to do iterative development, show the customer many releases, let the customer decide in which direction the project should go at every iteration.

But the biggest problem is, that you can’t tell what the project will cost the customer. Do you simply charge by hours/person days? Then it is no probleme to often change to whatever the customer wants, do many iterations. But the customer has no clue what the project will cost him.

Or do you have some nice way to convience the customer to accept the iterative approach (which i believe is the best for the customer) but he will not know what it will cost him – and many companies want fixed priced contracts which i think is not possible to do in an iterative approach because the customer can always change his minds (which is good) but will cause costs. So have always change requests for every iteration is not making a customer happy (nor the developer/dev leads/project mangers).
ScottBellware 10:09 pm on January 24, 2008

Jeff,

The essential goal isn’t to “have a place to enter maps and driving directions”, it’s, “to enter maps and driving directions”. The later is a more direct reflection of the behavior. All user stories can be written with some variation of “to have a…” For a great number of user stories in an analysis, you could use a dumb piece of software to clip that happy talk and end up with a story that’s truer to the user’s primary intentions. The “want to have…” stuff is a secondary intention and is implied by the fact that you’re writing software or creating some tool to address the primary intention. Peel the onion until you get down to the essence of the user’s wants. There are inevitably layers of happy talk that could surround the core of a story, and the sum of happy talk in an analysis inevitably leads to a degree of blur in the focus of the project and reduces the likelihood of satisfying the needs with the precision and accuracy that facilitates the next round of efforts.
Jeffrey Palermo 6:44 pm on January 27, 2008

@Eleaser,
You are correct in that you can’t tell the customer what it will cost. You can only estimate the cost. The customer also can’t tell you what the software needs to do. The customer can only share the business driver for wanting to create the software. Software consulting is as much a business partnership as anything else. We must embrace the client’s vision and together determine the scope, timeline, and budget to get there.

History has shown us that up-front attempts to define scope are not effective.
Jeffrey Palermo 6:44 pm on January 27, 2008

@Scott,
Thanks for the better wording of the story.
Olaf Teichmann 11:39 am on January 28, 2008

@Eleasar and Jeffrey,

Jeff is right, most customers won’t be able to imagine results prior to the end of the project. What I don’t completely agree with is that “they can’t tell you what the software needs to do”. In my experience, customers even rush forward too much in the first meetings describing where buttons had to go and which attribute fields they needed. This leads to a risk in agile development: going with the customer flow, defining stories and buttons together whithout understanding the underlying problem. A lack of sufficient conception has always been one of the leading factors of flawed IT projects, and the agile way might seduce you to take the shortcut where you should have stayed on the road.

Eleasar addressed another essential problem that I still have with agile development. While I disagree that “you can’t tell the customer what the project will cost”, because scope is moving not budget :-), I absolutely agree that customers are not happy to accept that the contractor may not beld held accountable for a defined result, especially when customer regulations command a fixed price contract. This might get less important with growing trust, but it surely is an issue with new customer relationships.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

How to write stories _before_ the project kicks off

Related