Tell stories to your developers, they like it

sto⋅ry
–noun
a narrative, either true or fictitious, in prose or verse, designed to interest, amuse, or instruct the hearer or reader; tale.

Easy story telling:

The above line reveals an important secret: a story is not always read. Given an option, most of us would like to hear the story from story writer rather than reading it. Thus:

• Shouldn’t we write stories in a way it is easy to narrate? (hmmm... 'Narrative'?)
• Is it possible to write a story in a way which is easy to remember after narration?

Provide Business Context

“Story is designed to interest and amuse the hearer or reader.”

How do I amuse somebody? I guess, by telling something they don’t know Or by confirming/contradicting what they expected to know.

The only way amuse a developer to provide a good and interesting business context for the story, at least to confirm what they are expected to know from business perpective. And, if you really able to tell something they don't know, you might really amuse your story listener.

Don’t forget to tell about lead character and his/her interest

Are you telling the story of a king or a Queen? It is about a Superhero?

Don't worry, if your lead character is a simple user of your application. Everybody likes to find out the lead character of the story and many a times it is a simple user.

Hopefully, lead character of your story is very clear in your mind. Would you forget to mention your lead character in your story? Hope not !! It would be a bonus to your listener if you can sketch the character of your story.

And what does your lead character wants to achieve in the story? Find Love or take Revenge? Won't you like to share this information with your story listeners?

Write Acceptance Criteria

So, you narrated the story. Your lead character wants to achieve something. Ask your developers to enhance the system in a way that your lead character finds what s/he is looking for. Your lead character might be lucky enough to follow "happy" path or they might take "alternative" routes to find the final destination.

Write acceptance criteria to fulfill wish of your lead criteria and let there be happy ending for your story.

Happy story writing :)

Business Analyst Check List

Going along doing our daily chores on the project there are few things which we should always keep in our to do. Some of them might already be on your checklist

1. Talk to your developers : The task of analysis is not complete with writing stories. I believe a story or a narrative is just for reference and should not compensate for an in-person communication between you and the developers working on it. In my experience there have been numeral instances where lot of things got uncovered in these conversations which were probably missing in the narrative or the story. The best way to make this happen is to try and sit next to the developer pair who is working on your story.

2. Test your story : Testing is not just a QAs or a developer's job. As a business analyst it is very important that you test and validate the story for its business completeness. Most of the time a business analyst on the team is acting as a pseudo customer. As we are closest to the business, its us who know most what the story should do and whether it conforms to the business requirement or not. So don't shy away from testing as it very important for your project's success. Most of the projects these days have formal BA sign-off stage for every functional story.

3. Seek early customer feedback : We have a formal stage in the release or an iteration where we seek customer feedback through showcase. But I would say why wait till then. If there is a feature which is on critical path and requires constant customer input, go an have an informal showcase with the business stakeholder or subject matter expert. Run it on dev box or your machine.

4. Prioritize : For a release, for an iteration, for a day. And not just stories, defects and tasks too. I know we are not the only actors here but we are one of the important ones. And its important that give our inputs where ever possible.

5. Look at the larger picture : Most of you would agree with me that for a Business Analyst it is very important to know the "WHY" version of every question being asked. Things like why is this project so important to the client's business ?, Why have the priorities changed ?, Why does the client need this feature ?, Why I need to do it this way and not that way ? etc. And the answers for these come when you not only understand the current requirement but where and how it originated from. On my current project, the BAs actively go and surf the internet for any blogs being written about our client, any press releases, any reviews or interviews. We exchange this information among us. This has helped us get answer to most of the whys.

If you have a to-do list of your own please share it with us

What skills should business analysts acquire to add value on a project?

One way for a business analyst to really add value on a project for a customer is when he/she understands the customer, industry and competition well enough to be able to give valuable solutions and suggestions. Analysts, in most of the projects that I have worked on, do not specialize in a specific domain. They start on a project with very little knowledge of the customer’s business and slowly learn the domain as they go. They are mostly taking requirements from the customer and managing scope. What should the analysts learn in order to really make a difference to the customer (and also remain in business ☺) and how should they go about doing this?

Do we need always need business analysts?

If the customer is reasonably clear on what they want and the nature of the application is such that unless you have a lot of business domain expertise you cannot really shape the requirements, then isnt it best that the customer interacts directly with the developers and get the app built? An iteration manager to coordinate things might be sufficient... Looks like BAs will be out of business soon ;-)