Writing good User Stories can be a daunting exercise. A proven way is to use the
AS A persona/role
I WANT goal
SO THAT business value
template with which the User Stories become much more tangible and more important of value to the customer. Watch out for 'and' or 'or' in the I WANT section, those often indicate a second User Story.
So far so good, but this still leaves the acceptance criteria out of the picture. Acceptance Criteria are a good guideline for developers to make sure they do the right thing right. It gives them a change to cover themselves with proper unit tests. QA also uses them as a testing foundation. Most important though, they are the definition of development done. (see 'Measuring Progress') Sure, the customer still has to like and accept them!
So that brought me to use:
GIVEN context
WHEN event
THEN expected outcome
With those kind of user stories you would think you are in pretty good shape. Well, you probably are in the remote case should you develop a programming tool. What does this mean? The more the development team knows about the problem domain the better they are off. Now, consider the case that you develop software for the financial, medical, nuclear or any other foreign field. Looking at the image below you are ok for as long as you stay in the green band where the requirements are clearly understood. In case of the mentioned programming tool your programmers will.
[Agile Software Development with Scrum; Prentice Hall, Ken Schwaber, Mike Beedle, p. 93]
Once you enter the red band, the team enters an unknown and not well understood territory. The User Stories might read like this.
AS A wombut
I WANT to blabalam amplituded chromioms in a shamaluk
SO THAT I can implotude the defused mobolobs
Makes any sense? If you are post-doctoral wombut it will. So, how can this knowledge be transfered to the mortal world of developers?
One option would be to have the wombuts and developers spent long hours together so that they get some understanding about the domain. The more knowledge is missing the longer it will take. Most often, however, wombuts are so busy that they can only spare an hour here and there. There might be some short hallway chats; but often those rise more questions then they answer.
Over the long run, this will lead to an information deficit and the resulting vacuum will be filled with assumptions. Don't assume -- if you assume you make an ASS of yoU and ME ;)
[The dotted line shows limited communication]
In the world of TOC (Theorie of Constraints) you can mitigate a constraint like this with introducing a buffer. The buffer enables you to be productive even though a upstream step is blocked. What could this buffer be? As the title already reveals, it would be a Business Analyst (BA).
[BA as buffer with good communication flow]
Having a Business Analyst will give you two things. First, knowledge you can access all the time; usually the knowledge of the BA is a subset of the experts but in general good enough. If the BA does not know an answer or isn't sure, she will follow up with the domain expert and report back and grow her knowledge by doing this. Second, the BA can help to bridge the communication barrier between the developers and domain experts. She is used to work with developers and understands how they think. Still, the lingua franca between both sides would be the User Stories with their acceptance criteria. If both the developers and domain expert are happy with the resulting User Stories then we have an agreement about how the customer value will be delivered.
What about the blue vertical band on the requirement image from above? The green/blue area is a well understood domain but is technically challenging. Think about the really fancy programming tool mentioned before -- for that strong programmers will be able to do the job. The red/blue area is when you need both; a BA and real good programmers.
Considering I lead a project in the plain red area (not red/blue) and I had to choose between a real good programmer or a BA, I would opt for the BA without hesitation.
Posts
