Tuesday, August 18, 2009

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

No comments: