If you’re a business analyst whose company recently made the move to agile, you may be wondering where you fit in when there is no business analyst role. Or maybe you made the move to be an agile business analyst or product owner but don’t know how your traditional business analyst skills figure into this new agile world. Well the good news is that even in agile frameworks with no official business analyst role, business analysis still needs to be performed for every product so that we know we’re building the right thing. It may be called something else and we may do it differently, but it is still a vital part of the agile process.
With this post, I want to talk about one piece of business analysis - visual modeling - and how it fits into agile and building a great backlog. In waterfall projects, the business analyst will typically gather all the requirements up front (prior to design and development) utilizing visual models to enhance and give context to her requirements. In agile, we do everything with “just enough” detail, “just in time” for the development team to start working on a given requirement or user story, so many people have taken the route that the user story along with conversation is enough and we don’t need visual models anymore. This couldn’t be more wrong! Especially with so many large, global companies moving to agile and having distributed team with lots of dependencies, visual models can help bridge communication gaps that co-located agile teams can cover with conversation.
So, why visual models in agile? Visual models arguably are even more important in agile projects than in waterfall projects because there is a low cost to build or change them. They are easy tools to use to gain understanding between the business stakeholders and the development team without having to spend a lot of time writing requirements or user stories. Additionally, visual models allow the product owner or business analyst to view the whole product and vision while focusing on a sub-set for delivery - enabling the product owner to deliver the most value the soonest. Visual models are a great supplement to the backlog and user stories to gain a richer understanding of the product and the needs of the users. They also help the product owner or business analyst find missing stories and acceptance criteria.
Which models are best in an agile process? We have 22 visual models in RML®, but not all of those are useful all the time, especially on an agile project. However, I’ve found that there are about 5 models that are used on almost every agile project I’ve worked on. Let’s walk through each one - in this blog post, I’m just going to give an overview of each visual model, but you can find more information in the links below.
Business Objectives Model: The business objectives model tells the team why they are working on a project or building a product. It is similar to a product vision, but gives concrete objectives that we want to solve with the project/product. On agile projects, this is probably the most important model because the product owner or business analyst should be tracing every single user story back to the business objectives model to ensure that we are only building what is needed and useful to the user.
Process Flow: Process flows detail out a business process from the user’s perspective. They can be at multiple levels (typically L1, L2 and L3 - starting at the highest, most-abstract level and working down in detail) and so are great for agile projects! At the beginning of a project, the product owner or business analyst can define the L1, high-level process to identify epics or features, and as iterations progress, can dig deeper into L2 and L3 detailed process flows. Each step in a lower level process flow is likely to be one or more user stories.
Feature Tree: A feature tree is a visual model that lists out all features for a product/project in a hierarchical tree format. In agile, this is a good tool to keep up with requested features because it is easy to update. By color coding or making important features closer to the “trunk” of the feature tree, you can easily show iterations or releases.
Business Data Diagram: The business data diagram shows all data objects in a project or product and how they relate to each other. On agile projects, this serves two purposes: as a catalog of the overall data needs (hard to show in a user story) for use in building databases and as a source of acceptance criteria to enforce the relationships between data objects. This is a lower level model and may be started in a sprint 0, but would need to be kept updated in subsequent sprints.
Decision Tree or Decision Table: Finally, decision trees and decision tables detail out system logic and how the system should respond to various input decisions. These can be used to expand a given user story with decision logic or can be used as the acceptance criteria themselves. Since one of the most common ways of writing acceptance criteria is the “Given, When, Then” format, this lines up nicely to decision tables, where the “given” is a precondition, the “when” is a trigger or decision and the “then” is the outcome. Decision tables ensure that every combination of decisions and outcomes is considered, so when using these for acceptance criteria it is clear to the developers and testers what should happen in every instance.
These are the visual models I’ve found useful on my agile projects, which ones do you use?