The Customer, part two

by Paul Klipp

Welcome. We’re delighted to work with you. If you’ve read my previous article on choosing the right customer and you’re feeling stressed, read on. Here is what you’ll need to do in order to ensure the success of your project. It’s not so difficult.

The customer is responsible for writing user stories.

That doesn’t mean you have to sit down and write all of them, but you can. It does mean that you have to ensure that all of the user stories written by you, by the developers or project manager, and by other stakeholders do an adequate job of describing the desired results. You will have to read all of them, edit them, and confirm their fitness during the Planning Game. The software vendor can’t start development until you do.

What is a user story?

Traditional software development processes use variations on the functional specification to describe functionality. That method works very well if you write well, have a lot of money for up-front design, know exactly what you want, are certain that the business case the drives the project won’t change at all, and you are certain that all stakeholders also know exactly what they want. Then you can write one document describing every aspect of the application in detail and we will estimate it and code to spec. However, if there is a chance that the specification will change (they almost always do) because during the project anyone at your company has a new idea, your competitor has a better idea, or your customers have a new request, then an agile process will reduce your costs and greatly expand your flexibility. Agile process use user stories to describe functionality. A user story is a short, one to three sentence, description of the desired behavior. Here is an example:

That’s a simple user story, it’s only two sentences long, but describes clearly what you want the programmers to do. An entire software project is defined by dozens of such user stories. The beauty of user stories as opposed to a functional specification is that they can be far more easily changed, added to, and organized into different priorities than can a single functional specification. Also, it is much easier for more stakeholders to participate in the creation of user stories than in the creation of a functional specification. You might have some specific ideas about how this should work, and there is no rule against adding supporting documentation to a user story. If you are proficient with graphic design tools you are always very welcome to attach mock-ups, wireframes, or even just rough sketches of your ideas.

Be warned, though. User stories are deceptively simple. Your job is to make sure that they contain the necessary information to ensure that the developers can properly interpret your desires. Consider this user story:

This story would result in a working function. Users could register for access to the application. However, it ignores the business case behind the story. It’s your job to know that the reason users register at all is so that your marketing department can collect working email addresses and job titles so that they can more accurately target their message to people who perform specific functions (specifically, CEOs and Human Resource Professionals).

Now that we know the business case behind the story, we might do an even better job.

This story is more aligned with the business case than the first story because it more clearly identifies heads of companies and human resource workers without having to search through user-supplied text which could be misleading. For example, under the first story a human resource worker with the job title “compensation analyst” might not be included in a marketing distribution to HR users because there are no clear HR-related keywords in the job title. Under the second story, they would clearly be identified as a human resource professional.

Now, are you seeing why your role is so critical and why it demands clarity of thought and focus? A less competent “customer” might have been satisfied with the first user story, but a few months down the line, when marketing expressed their dissatisfaction, even after the programmers made the necessary adjustments, a developer would have to write a script to assign users to job categories based on thier job titles and some salary-gobbling human would have to invest time in sorting through the already-registered users who slipped through the cracks and assign them to the new categories by hand.

While I’ve never required it of a customer, I recommend that the person in that role write a vision statement that defines the business case. Such an act has two major benefits. One, by sharing the vision with the people funding the development the customer can refine her understanding of the business case. Two, by sharing it with the development team the programmers learn why they are being asked to do what they are doing and can therefore better anticipate the client’s needs and will make better decisions during the development phase of the project.

The customer also defines the acceptance tests. These test should be easy to compose from the user stories. For example, for the story above an acceptance test might be:

When a user creates an account using the name John Doe and email address jdoe@hotmail.com, chooses the HR job function, and a password of hi776 and clicks submit, his submission will be rejected on the basis of the length of the password. When he chooses instead the password hi776bke, then a new user record is created in which all fields are correctly populated. A confirmation email is sent to jdoe@hotmail.com containing the user’s correct login details.

This is a test that is clear, easy to run and check, and as you can see, flows naturally from the user story. This test serves two purposes, it allows the developers to better understand the customer’s expectation and it allows the customer to easily verify at the end of the iteration that the user story has been properly implemented. The acceptance tests do not have to be written before development begins, but can be written while development is taking place. The tester will use the acceptance tests to verify the success of the iteration.

So, what does your life look like?

Your experience as customer varies during three phases:

The Planning Game

(about 1-2 hours per day)

At the beginning of the planning cycle you will write the project vision based on the business case and present it to the stakeholders for approval. Then you will share it with the development team.

During the planning cycle you will work with the team to compose user stories and verify that each is as good as it can be.

You will then prioritize the user stories as high, medium, and low (or with greater degrees of granularity if the project merits it).

At the end of the planning cycle, the manager will create an iteration plan based on the developers’ time estimates and your priorities and will submit it for your approval. This is your last chance to ensure that your stories and priorities are accurate reflections of the stakeholder’s desires (for this iteration, you can change all you want between iterations). With your approval, the development phase begins.

Development Phase

(about 15-45 minutes per day)

During development (or before) you will write acceptance tests for each story slated for the current iteration. Other stories may change as a result of your experiences with this iteration, so they are best set aside until the next planning cycle. The tracker or manager will keep you appraised of the team’s progress by tracking velocity, or the rate at which stories are closed. When each story is closed, the team will frequently update the integration server where you can test the implementation for yourself if you choose. The developer will also send a closed story email including screen shots of the implementation as each user story is implemented. There is no better time to adjust misunderstandings then when the code is fresh in the developers’ minds, so your prompt feedback, while slowing velocity, will overall improve efficiency. During development you can expect to spend roughly 15-45 minutes a day reviewing progress and offering feedback.

Testing Phase

(about 15 minutes per day)

After development is complete, the testers will confirm that unit tests do not fail and will run your acceptance tests. You will be appraised of the metrics produced by these two processes. Your role during this phase is simply to answer any questions regarding desired functionality that the testers or developers may have.

Deployment

(variable time commitment, depending on the situation at your workplace)

(this is when your job really begins. The workload depends on the scale of the deployment and on how much support and buy-in you’ve managed to generate in your organization for this project). It is up to you as the customer to declare when the business value realized by an iteration is sufficient to merit deployment in your organization.

In conclusion, the strength of agile development is that rather than spending an enormous amount of time defining the project up front and then waiting patiently to see the results, you spend only a small amount of time daily driving the project and course-correcting as needed so that in the end, you arrive right where you want to be. The tasks are not difficult or time-consuming, but the responsibility is great. You must be prepared to devote a little time every day and during that time, to give the task at hand your full attention and concentration. If you’re ready to do that, then you can be my perfect customer.

copyright 2005 Paul Klipp