The second part of the Business Analyst brown bag session just ended. Knowledge sharing has always been a part of Flexisource IT’s goals. That’s why we had our very own Berlyn Decena share her specialty with our employees.

Berlyn’s BA role sounds intimidating at first glance. However, the brown bag series has proven that–with a few business analyst courses, you can become a business analyst. 

The second part of Berlyn’s brown bag session discussed how to make actionable user stories, the importance of acceptance criteria, and how to collaborate properly with the development team.

Recap of the Previous Business Analyst Session

Previously, the first session was an introduction to BA responsibilities and how they provide optimisation for every project. This included discussing user stories, the importance of the acceptance criteria, edge cases, and the general day-to-day tasks of a BA. 

For the second part of the session, Berlyn made a note to explain further how to create user stories and a more detailed understanding of acceptance criteria. 

Organising Scopes as a Business Analyst

The first thing the session provided was an example. What if your team was assigned a task to create a sign-up functionality? There she showed that the first thing to do is to create and organise your scope.

A scope contains the basic requirements the assigned task needs. This should include a clear definition as to what the assigned task covers and take notes on what is specifically requested. Once you have the scope and the steps including the requirements it’s time to imagine the journey of the user.

This journey can be mapped out using flowcharts that provide a visual of possible encounters the user may experience.

How to Make Actionable User Stories

When making user stories there are four key factors to consider. These factors can make the user stories more actionable and easier to read for the entire team. Alongside the guidance of your user journey flowchart, these factors can make actionable user stories.

Key Factors in Actionable User Stories

Edge Case Notes – User stories must have logic, validation, and conditions clearly defined.

Business Rule – Timeouts, invalid inputs, and large file sizes should be considered.

UI/UX Expectations – Mockups or describe key layout behaviours should be written down.

Error Handling – User stories must describe what should happen during a failure such as automated prompts.

Deep Dive on Acceptance Criteria

Acceptance criteria are important for a business analyst. Business can’t grow if the project fails to meet the criteria set by the BA.

The criteria of acceptance should follow the BDD Style (behaviour-driven development), highlighting the prompt when the user makes a specific action that then leads to another. In other words, an acceptance criterion discusses a specific scenario and the natural responses it should include within the project.

Included in the acceptance criteria is a rule-based format gathered from the BDD style. It’s the ideal format for UIs, validations, and permission logic.

A great piece of advice Berlyn gave was to be narrative-driven. It should remain clear and useful throughout small user stories to make it more effective.

Key Takeaways

There were a few key takeaways that everyone should remember when creating user stories. Additionally, Berlyn made sure to explain to the audience what to do if there is no BA available within their team. 

Clarity over Complexity

The knowledge-sharing session expressed heavily how clarity is much more important than complexity. User stories should be divided and have less information between sections. This method makes it easier to be clear and concise, leaving little room for miscommunication.

Collaboration is Important When Making User Stories

While BAs spearhead the creation of user stories, it’s important to involve the development team in its creation. Everyone contributes with feedback and mutual understanding regarding the user stories, providing insights only people with their perspectives can provide.

No Business Analyst Means Team Effort

There are situations when a BA is not present within a team. During these scenarios it’s easy to experience misunderstanding requirements, a disorganised way of testing the program, and general delays. 

To prevent this, Berlyn gave a piece of advice to the QAs and developers present in the audience:

• Always ask questions, collaborate, and document assumptions.
• Lightweight tools for consistent templates are necessary to align all team members.

Conclusion

The business analyst brown bag series still has more up its sleeve. Stay tuned for more information that can help you identify the important role of a BA in agile methodology.

Did you miss out on the previous brown bag session? Don’t worry! We have a recap for the first BA brown bag session right here!