How many times have you heard someone say “A Business Analyst’s job ends when the requirements are documented”?
In my career I have been told this statement many times or have overheard it being said to other people. This has been the starter to many heated discussions. I always speak up to explain why that makes for a poor Business Analyst, a poor product and most likely many defects after the feature is coded.
When I think about my role, two things come to mind:
Those may seem like two independent items and we could have an entire discussion on each of them, but I’m going to touch on how you can truly own your features while cultivating a collaborative approach.
As a Business Analyst I find it important to be more than a scribe, more than a note taker, more than someone that sends out meeting minutes. My most successful projects are when I take ownership of my requirements, my feature, and my job and collaborate with everyone on the project to ensure we deliver not only what the customer is requesting, but a feature that is also beneficial to the core product.
Owning a feature is contrary to the statement – “A Business Analyst’s job ends when the requirements are documented.” If you truly only had to document a requirement, you’d never speak to an Engineer, you’d never know what a Test Manager does, you’d never see the end product or hear the joy and disappointment that can come from the customer. You would never know if what you documented is in line with what was developed. I don’t know about you but if I’m going to spend time documenting something and learn the ins-and-outs of something, I want to see it through to the end.
How can you own a feature without collaborating with the team?
Our role starts at the beginning of a project or release. At a high level the phases a Business Analyst will go through for features are; Product Discovery, Impact Assessment and Capability Analysis, Detailed Design and Documentation, Commercialization.
This is where a feature is born. The customer has a request, a problem or an idea and the Business Analyst discusses with the customer to capture the full understanding of what the problem or issue is that we are trying to solve for.
Impact Assessment and Capability Analysis
During analysis the information gathered from the customer is checked against the existing products to see if we can solve the problem with existing functionality or make small tweaks to existing functionality. The Business Analyst will also reach out to the Business Analyst Community and search requirements backlogs to see if anyone else is working on a similar feature. By the end of analysis, the Business Analyst will have an idea on how to craft the requirements for the customer.
Detailed Design and Documentation
Once we have determined what the “ask” is and have an idea of what to do with it, then it is time to design the solution and write the requirements. During this phase a Business Analyst works with engineers, interaction designers, and architects to help flush out a design and get high level estimates.
The Business Analyst decomposes a feature into stories, typically independent small pieces of work that make up a feature. By breaking out the requirements this way, the engineers can start working sooner and clearly divide the necessary work. It is easy to think a Business Analyst is not involved here, but we are! The Business Analyst should have a walk-through of the requirements with the engineering team and be available during the code period to answer any questions. During the code phase there may be a time where it is discovered a part of the feature simply can’t be done or be done as planned. The Business Analyst works closely with the engineers to collaborate on the issue and a new solution, in order to take that back to the customer for feedback.
I am a firm believer that a Business Analyst should test the features they own during the testing phase. For starters I always want to see the finished product of something I own. I also know that as a Business Analyst this was my “baby”; a feature I owned from the beginning. I know what I expected it to look like and what the client expected so it is important to me to review this to ensure that the success criteria has been met. Formal testing teams will conduct extensive testing but as a Business Analyst I find it a good practice to run through the functional testing. This gives the Business Analyst a feel for the new feature, and helps the Business Analyst to answer questions from the testing team.
Business Analysts are involved with the release and after a feature is in production they are called upon to answer questions, train people and if a defect is filed typically the Business Analyst is the first person everyone goes back to for help. It is important to help with Commercialization. By training, providing release notes and communicating what was built the Business Analysts help to spread the word on new features as part of driving greater awareness and adoption of the capability.
Own your role, own your craft
On a daily basis I collaborate with Engineers, Technology Delivery Managers, Quality Assurance Analysts, Test Managers, Solutions Owners/Consultants, and many more roles. I believe it is in our role to be expert communicators and collaborators with the stakeholders for a feature. A Business Analyst works in all phases of the SDLC and during this we watch our “Baby” grow from an idea into something that is real and a valuable to customers.
To be successful you have to own your role, be more than a documenter, do more than the bare minimum; be the guide all the way to production, ask questions along the way, collaborate, communicate and constantly analyze; own your craft.