Business Analysts are Important

I’ve always been convinced that User Stories are the way to describe feature requests. It just felt natural. IEEE 830 specification are just too ambiguous. Use Cases, even far more verbose, are often too large by covering all possible flows and exceptional cases. User Stories just fit the bill.
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.

PrjCom

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 😉

DevDomainConstraint

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).

DevBADomain

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.

About Effective Agile

Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and also a Professional Scrum Trainer based in Europe.

As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #scrum.org certified courses.

If you’re looking to invest in training that transforms and empowers teams to successfully adopt #scrum or #agile, and create high-performance #productdevelopment environments leveraging the agile values and principles, visit our Professional Scrum Training page.

If you would like to work with Ralph and company as an #agilecoach, #agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #agile #productdevelopment, connect with Ralph Jocham.

For more great ‘how-to’ videos, blogs, and insights, subscribe to our YouTube channel and visit our blog for more valuable content.

#scrum #agile #scrumorg #scrumcertification #scrumcourses #scrumtraining #agilescrumtraining #agilekata #agility #businessagility #agileprojectmanagement #projectmanagement #productdevelopment #agileproductdevelopment #switzerland #germany #europe #scrumteam #scrumframework #professionalscrumtrainer #PST #certifiedscrumtrainer #certifiedscrumtraining

Latest Short Videos