I recently announced that I’m not a Business Analyst, I’m a Business Analyst Designer. A job title is all very well, but it’s not much use without a job description. I have already waxed philosophical about the designer mindset – there’s no such thing as a requirement and it’s all design. But I haven’t said explicitly what a Business Analyst Designer actually does.
In this article I introduce the Business Analyst Designer Method – the method I follow as a Business Analyst Designer. I’ve been evolving it over the past few years, and it’s now stable enough to be worth sharing.
Business Analyst Designer Method (BADM) is a method for designing business change, especially where there is a significant component of IT system change.
BADM embodies agile principles – it is lightweight, encourages incremental delivery and collaboration, embraces change and prioritization, and focuses on delivering maximum business benefit as early as possible.
That said, BADM is applicable to both agile and non-agile projects, although it leans more towards the former. On agile projects (XP/Scrum in particular), it fills a gap by recognising that it is important to spend some time and effort deciding what to build before building it. On non-agile projects it empowers business analysts to add more value than they would by merely “gathering requirements”. It also allows non-agile projects to adopt some key agile principles without “going agile”. Put another way, it provides the opportunity to introduce agile by stealth.
BADM introduces a new role – that of the Business Analyst Designer. On agile projects, the Business Analyst Designer role replaces/extends the Product Owner role. On non-agile projects, it replaces/extends the Business Analyst role.
BADM is prescriptive, but in a good way, in that it explains what to do, in what order, and includes templates for the various deliverables.
BADM is centred around the concept of features. A feature represents some useful component of business change, and is also the unit of delivery. Features go through a micro-lifecycle in BADM – they are requested, defined and designed – and subsequently allocated to increments and delivered, as illustrated below:
The most important part of BADM is the Define phase, and this is where the Business Analyst Designer adds most value. In particular, it includes two very powerful concepts:
- Options engineering – discovering the underlying business objective and thinking of alternative ways to fulfil it
- Feature splitting/phasing – avoiding or delaying delivery of low priority capabilities by splitting features into “the important stuff” and “the rest” (maximising the amount of work not done)
The key benefits of BADM are:
- It is more predictable than XP/Scrum
- It delivers business benefit sooner than waterfall, and is cheaper overall (by approximately 30% in my experience)
- Its focus on conscious design results in higher quality outcomes than the alternative approach of “gathering requirements”
Why Another Method?
I’m a big fan of agile software delivery. Well, I’m a big fan of the principles of agile software delivery. But the de-facto standard agile method (XP/Scrum) has something of a blind spot when it comes to analysis and design. XP/Scrum seems to assume that deciding what to build is relatively quick and easy. In particular, it assumes the following:
- Business stakeholders (or product owners) know what they want well enough to be able to articulate it as a user story
- What a business stakeholder thinks he wants is actually a good idea
- Developers all have the requisite communication and design skills (and the inclination) to work with business stakeholders to agree good quality acceptance criteria for user stories
- Agreeing acceptance criteria with a business stakeholder is quick and easy, and waiting for answers won’t hold up progress in a sprint
In my experience, the above assumptions are false at least half of the time. Business stakeholders don’t always know what they want, and sometimes what they think they want is either not the best way to achieve the underlying objective or else it is just a plain bad idea. Some developers are good at communicating with business stakeholders. Some are good at functional design. Some are lucky enough to be good at both. But not all, indeed, not many.
It takes a combination of skills, and most of all it takes time, to decide what to build. For me, the approach of putting developers together with stakeholders, under the tight pressure of a sprint deadline, and expecting a good design to emerge, is not the ideal approach.
So over the past few years I have developed a method that “plugs the gap” in XP/Scrum and provides a relatively agile process for feeding well-defined user stories to agile delivery teams to build.
To my surprise, the method also appears to work on waterfall projects. It has just enough rigour to keep the quality/method police happy, but opens up the possibility of introducing agile principles by stealth, without officially “going agile”. One project I tried it on was saved from probable doom by introducing BADM part way through.
The method has evolved over the course of several projects, to the point where it is fairly repeatable and seems to handle most of the business analysis scenarios that I have thrown at it.
All in all, I feel the method has been successful enough to be worth sharing.
A Partial Method
BADM is not a full software delivery lifecycle. It primarily covers what I call the design phases – from the point of receiving a request for business or system change to the point of having decided what to build at a detailed level (system functional design).
If you are familiar with agile (XP/Scrum) software delivery, the best way to think of BADM is as a process to manage the product backlog and to feed well-defined user stories (including acceptance criteria) to the delivery team to build.
If you are familiar with more traditional business analysis tasks and techniques, think of BADM as the process of “eliciting requirements” up to and including the delivery of a functional specification which developers can use to build software, but with an emphasis on incremental delivery and conscious design.
The Business Analyst Designer
I recently declared myself to be a Business Analyst Designer. It’s a role I invented because none of the existing roles in common usage (Business Analyst, Solution Architect etc.) quite seemed to fit how I work.
A Business Analyst Designer is somewhat analogous to a building architect. He (or she) works with the client to understand the project objectives and then designs something that meets those objectives. He does not gather or elicit requirements and then hand them over to a (separate) solution team. He is both the listener and the designer. He challenges. He sketches out alternatives, highlights the pros and cons of each, and helps the client decide which option they prefer.
The Business Analyst Designer Method is, as its name suggests, a method for Business Analyst Designers.
On agile projects, the Business Analyst Designer role replaces (or extends) the Product Owner role. Unlike the Product Owner, the Business Analyst Designer is explicitly responsible for functional design, not just for managing/grooming/prioritizing the product backlog.
On non-agile projects, the Business Analyst Designer replaces (or extends) the Business Analyst. Unlike the BA, the Business Analyst Designer is explicitly responsible for functional design, not just for “eliciting the requirements”.
Incremental Delivery, Prioritization and Change
A key feature of BADM is that it supports and encourages incremental delivery and prioritization. It adopts the XP/Scrum concept of the product backlog – a prioritized list of “things to build”. XP/Scrum calls the things to build stories. BADM calls them features. There is a reason for the difference in terminology which I’ll explain later.
BADM takes the product backlog concept a step further by emphasizing the importance of feature splitting – the conscious process of splitting features into sub-features in order to delay (or avoid) the delivery of low value functionality. This is similar to the XP/Scrum practice of splitting epics into individual stories, but with a very specific aim.
BADM embraces change. As with XP/Scrum, this is done via the product backlog – features can be added at any time and are prioritized relative to other features.
These techniques can also be be used on waterfall projects, but need to be applied in a slightly different way to tie in with project phases and change control processes. If you are looking to introduce agile by stealth, this is your way in!
For more details on the importance of prioritization, and why incremental delivery is so useful, see my article on how to prioritize requirements.
Close to my heart is, of course, the concept that the process of deciding what to build is a process of design. There is no distinction between “gathering requirements” and “designing solutions”. It’s all design.
BADM encourages conscious design by including specific steps for identifying alternative options, evaluating the options and selecting a preferred option (including the option to do nothing). This might sound like a trivial point, but it’s all too easy to take a stakeholder “requirement” at face value.
BADM also encourages conscious design by forcing you to write acceptance tests, not merely acceptance criteria. Much like (written) use cases, acceptance tests make you think through the dynamic behaviour of your system and, in particular, identify how to deal with alternative flows and edge cases.
It is often said that the role of the Business Analyst is bridging the gap between business and IT, allowing effective communication to occur. But done badly, Business Analysts can actually widen the gap by becoming an inpenetrable barrier to communication. I have seen this many times in the form of requirements documents written and approved with little or no involvement from the technical team.
In line with agile principles, BADM recognises that the better designs emerge when teams collaborate – in particular, when developers and business people are in the same room.
BADM encourages collaboration in the following ways:
- Requiring business stakeholders and technical folk to be involved at all stages
- Capturing designs in slide deck format (as opposed to document format) – which is much more conducive to round-table discussions than off-line review
Repeatable and Prescriptive
BADM has evolved to a point where it can be described as “repeatable”. In other words, each time I execute it, I perform the same steps in the same order and produce the same types of output. I have used it enough times to know which steps are optional and which ones aren’t.
I have deliberately tried to make BADM as prescriptive as possible. The idea is that you should be able to pick it up and actually use it, like following a recipe in a cookbook. I’ve tried not to skimp on the details. I’ve included templates for the various (lightweight) deliverables, and a number of worked examples.
There’s a caveat. Design is, of course, a creative process – some might even say an art. BADM doesn’t mechanise the creative process. It provides a structure in which the creative process can operate. In my experience, good design itself comes only with practice!
Overview of the Method
OK, that’s the preamble out of the way. Let’s take a look at the method itself. BADM consists of three phases, as illustrated below:
Don’t be fooled. BADM is not a waterfall method. Rather, each phase is executed in turn on individual features to be delivered. At a given point in time, different features can be at different phases in the process simultaneously. And there is likely to be a gap between phases for a given feature (hence the clock symbols). Judicious use of prioritization and feature splitting ensures that people are always working on the most valuable things. Hence, BADM is waterfall on individual features, but the overall method is incremental/iterative, as illustrated below:
Any agilists reading this will immediately be horified by the idea of a waterfall process, even within the context of individual features. But hear me out. Here’s what’s bad about waterfall delivery:
- Needing to complete a given phase for all scope before being allowed to start the next phase
- Heavyweight documentation
- Lack of collaboration
But waterfall does have one excellent property: deciding what to build before building it. BADM captures this benefit of waterfall whilst avoiding the downsides. We work one feature at a time, the documentation is lightweight, and the approach forces collaboration.
Let’s now have a look at the individual phases within BADM.
Phase 1: Request
In the Request phase, a business change is requested. Requesting a business change is deliberately very easy. Anyone can request a change – a business manager, a business team member, a business analyst designer, a member of the technical team. All they need is an idea. At this point, it doesn’t even have to be a good idea – bad ideas get filtered out later in the process. In fact it doesn’t have to be a concrete idea on what to change. It might merely be a desire to improve some area of the business, perhaps to “fix” a perceived “problem”.
A requested change can also be of any size. It might be a small change to an existing business process and/or IT system, or it might cover the delivery of a completely new IT system. Large changes get broken down into smaller sub-changes later in the process.
A requested change is added to the Product Backlog and given a unique ID for tracking purposes, at which point it becomes a feature. I have deliberately avoided the term user story because it has a strong association with XP/Scrum and thus has negative connotations for anti-agile managers. Either term will do.
Optionally, further information about the requested change is documented in a Feature Request (a simple one page document). This is useful on larger projects or if, like me, the Business Analyst Designer has poor memory.
The Request phase also includes a brief triage of the feature to determine, where possible, a very rough estimate of size (using T-shirt sizes – small, medium, large, extra large etc.).
The Request phase finishes with an initial prioritization of the feature, which determines how soon (if ever) it will proceed to the next phase. Getting the priorities right is very important and, in my experience, extremely hard.
Click here for more details on the Request phase.
Phase 2: Define
In the Define phase, a feature is transformed from an idea into a scoped and sized business change. This is the most important phase, because it’s where all the clever thinking occurs, and where the Business Analyst Designer adds most value.
In this phase, the Business Analyst Designer asks the question, “what are you trying to achieve?” Traditionally, BAs refer to this as finding the underlying business need. I prefer to refer to business objective rather than business need (calling it a need implies that it is non-negotiable). Once the objective is understood, the Business Analyst Designer works collaboratively with the stakeholders the generate as many design options as possible to achieve the objective. Each option is weighed up for pros and cons (or benefits and costs) and a preferred option is selected. If none of the options has benefits that outweigh the costs, the selected option might be to do nothing. This is where bad ideas get filtered out.
An important part of the Define phase is feature splitting. Large features are split into two or more sub-features – the first sub-feature consisting of the highest priority component(s) of the feature, and the remainder being added to the Product Backlog to be prioritized and looked at later. This process is similar to the XP process of splitting epics into individual stories, but with a specific focus on delaying (or avoiding) the delivery of low value functionality.
In the Define phase, the selected option is elaborated to a point where it is possible for the delivery team to be able to estimate its size. This size is measured in feature points, and indicates the approximate effort required to deliver the change, relative to other features (similar to XP story points).
Finally, with the benefits and costs in hand, the feature is the re-prioritized against other features to determine whether and when it should proceed to the next phase.
Click here for more details on the Define phase.
Phase 3: Design
This is the easy bit. If the Define phase was done well, then the Design phase is simply a matter of filling in the details. It involves producing a detailed functional design for any IT system changes and, where relevant, business process designs for any business process changes.
Similar to XP, the functional design for a feature consists of a set of acceptance criteria that define what constitutes “done”. Specifically, the acceptance criteria are written as acceptance tests, in a form very similar to (written) use cases or BDD scenarios, and are used directly for both build and test (thus avoiding the need for separate test scripts). Supporting information such as data models or user interface designs/prototypes are also produced where appropriate (and only if they add value).
The output of this phase is a functional design (and business process design) that is agreed by all parties.
Click here for more details on the Design phase.
After BADM: Build and Test
BADM is primarily intended to be used within the context of an incremental delivery lifecycle. Features are grouped into increments for delivery in much the same way as they are in XP/Scrum – based on the duration of the increment, the team’s “velocity” and the size of the features.
Using BADM within a waterfall context is possible, but the benefits of feature-splitting and prioritization are lost, or at best, reduced. BADM is a good way to introduce incremental delivery by stealth onto waterfall projects – the Business Analyst Designer initially claims that they are merely prioritizing their analysis/design work, and then, at the point where some features are ready for build, suggests to the project manager that the development team could get ahead by starting early on those features, thus staggering the delivery. It’s not an easy sell, but it’s worked for me in the past.
Either way, sooner or later, it will be time for build and test to start.
In terms of build, developers code directly from the functional design, rather than from some intermediate “technical design” document – in my experience, such documents are a re-hash of the functional design and add very little value. That’s not to say there’s no need for technical design – architectural patterns, structures and patterns are important, and might be written down, but just not a technical interpretation of every single function.
In terms of test, exactly how the functional design is used for testing depends on the project’s test strategy. My preferred approach is to use the acceptance tests directly for system test and then achieve user acceptance by showcasing the system testing, rather than having a separate phase of user acceptance testing. For XP/Scrum teams using TDD/BDD, the acceptance tests in the FDD are converted directly into automated acceptance tests.
BADM does produce some documentation. In line with agile thinking, the documentation is designed to be barely sufficient. In particular, the documentation produced is so minimal that it forces collaboration because it cannot easily be used without some form of verbal explanation.
The four key documents are as follows:
- Product Backlog (spreadsheet) – the log of all features, their current status, priority and other meta-data. Features are added in the Request phase and updated in the Define and Design phases.
- Feature Request (document) – a simple proforma that can optionally be used to capture details of a requested feature in the Request phase.
- Feature Scope Definition or FSD (slide deck) – the main output of the Define phase – a slide deck presenting the opportunity space, all design options considered and the option selected, as well as its estimated size. Any feature splits are also identified.
- Functional Design Document or FDD (spreadsheet) – the main output of the Design phase – a set of acceptance tests that define what “done” looks like for the feature.
The process does include some very lightweight document approvals. The FSD is approved by three people: the business owner, the Business Analyst Designer Lead and the Technical Lead, and this approval is done in a meeting following the presentation. The FDD is reviewed collaboratively in a meeting and approved in writing (i.e. by email) by a single business sponsor and a single technical lead). This might seem like overkill in these agile days, but my experience is that some form of lightweight approval has a number of useful benefits, not least of which is to force both the business and the technical team to commit to what is to be delivered, and thus reduce the risk of spurious mind changing (we embrace change, of course, but we want to avoid constant changes in direction). It does also allow for the possibility of fixed price (per feature) delivery.
BADM revolves, of course, around a key role – the Business Analyst Designer. But there are some other important participants in the method. The following diagram illustrates who they are:
Here’s a bit more detail on the roles:
- Business Analyst Designer – for a given feature, this person executes the vast majority of the steps in the method and owns the deliverables.
- Business Owner – for a given feature, there is a single business owner. This person represents the business for the feature, and is actively involved in the high level and detailed functional design.
- Technical Owner – for a given feature, there is a single Technical Owner. This person is actively involved in high level and detailed functional design, and is responsible for ensuring the design is technically feasible. They also provide the feature point estimate in Phase 2.
- Business Analyst Designer Lead – has overall ownership of functional design for the system under construction. Owns the product backlog. Allocates BADs to individual features. Peer reviews FSDs and FDDs for consistency and overall design coherence. On smaller projects, a single person might be both BAD and BAD Lead.
- Business Sponsor – for a given feature, there is a single business sponsor. This is typically a budget holder i.e. the person who is paying for the work. Ideally, there is a single business sponsor for all features on the product backlog, but if the system under construction caters to multiple business areas, there are likely to be multiple business sponsors. The main job of the business sponsor is to prioritize their features (and in particular to agree/argue priorities with other business sponsors). Their other job is to formally approve for FDDs. They also allocate business owners to individual features.
- Technical Lead – this person has overall ownership of the technical design of the IT system under construction. Responsible for allocating technical owners to features and formally approving FDDs.
As mentioned above, BADM is a method I have evolved based on my own experience, on both agile and non-agile projects. It has worked for me so far. It might work for you.
I’m not saying it’s universally applicable. I’m not saying it’s all new – I’m aware that many of the concepts I use are already described (perhaps using different terminology) in other industry-standard references (such as the BABOK). But I have yet to find an existing method that emphasises the importance of conscious design (as opposed to “gathering requirements”). This is embodied in BADM’s Define phase and, in particular, in the activities of option engineering and feature splitting/phasing.
I’m sure BADM will evolve further as I continue to use it. It has evolved already over several years’ use so there’s bound to be more. But for now, this is it. I hope you find it useful. As usual, feedback is very welcome – especially if you’ve had a go at using it!
The following articles provide further details on various aspects of BADM: