Business analysis plans ultimately come down to setting expectations about how you’re going to work with your team and identifying the stakeholders you need to interact with.
These business analysis plans are typically used when you do most of your analysis at the beginning of an initiative. In this setting, it makes sense to highlight what deliverables you’re going to produce, when you’ll produce them, and who you’ll talk to when you need to do that.
When you work in an iterative fashion, you don’t really have a plan per se. You still set expectations with your team, but those expectations are about how you work with them on an ongoing basis. This may include establishing agreements about how you refine features or describe stories. It’s also about a simple process you follow to elaborate backlog items.
You also want to establish working agreements with your team so that you can build a common understanding about how you’ll work together.
You also want to know what stakeholders you need to work with.
Here is a collection of resources about working with your team to set expectations about how you’ll work together and some thoughts on identifying the stakeholders you need to interact with.
What does an agile business analysis plan look like?
An agile business analysis plan is an agreement within your team about what information is needed to build a shared understanding of your solution. This is the fifth in a series of posts about the agile business analyst.
Getting Tactical: Product Team Working Agreements
Assumptions in business can kill you, and assumptions on a team can do the same. One of the best way to preserve a transparent, low-politics culture is to keep everything as visible and explicit as possible. This applies to strategy, vision, and values, but also to working methods.
Giff Constable describes how the teams he worked with implemented written team working agreements that covered working methods such as agile flavor, recurring meetings, working hours overlap, story writing and prioritization responsibilities, work in process limits, coding/testing/deploying responsibilities,
How to set role expectations and working agreements
Conflicts in teams about how to work are common. There are expectations from team members on each other that aren’t being met. In a given team, members might be implicitly expected to perform a certain task. The team might have unspoken policies that seem to be common sense. Sometimes people pick up on these unspoken rules and implicit expectations, but when they don’t, you have a team in conflict.
You can’t avoid all conflict (and a dose of healthy debate and discussion is good for teams), but you can help teams by explicitly defining the roles and working agreements. Instead of dealing with conflict after the fact, you start with discussion and agreement.
Yassal Sundman uses this workshop with her teams and organizations to explicitly define roles and working agreements.
An exercise for creating a team Working Agreement
A Working Agreement is a valuable tool to use for establishing a shared understanding, and way of working for teams. Also called a Social Contract, this practice is a great foundation for building high performing teams. Bevan Williams shares an exercise to create Working Agreement adapted from Esther Derby and Diana Larsen’s 5 step structure from their book Agile Retrospectives.
Pay attention to your stakeholders
In addition to setting expectations with your team, another thing you need to do when starting an initiative is identify the key stakeholders you need to interact with. Here are some techniques and perspectives that I’ve found helpful for identifying and working with stakeholders appropriately.
The context diagram shows how your product interacts with outside people, organizations, and/or systems. The context diagram helps you to identify the interfaces you need to account for, helps you to identify scope, identify potential stakeholders, and build a better understanding of the context in which you are working.