This article provides a detailed description of Phase 2 of the Business Analyst Designer Method – Define.

Overview

The Define phase is all about understanding the business objective, deciding how best to meet that objective, and determining how much effort that would take.

The following diagram illustrates the inputs and outputs for the Define phase:

The following diagram illustrates the individual steps in the Define phase:

Phase 2 Inputs

The Define phase starts with a feature that has been:

• Requested by someone (anyone)
• Added to the Product Backlog and given a Feature ID
• Optionally, been written about briefly in a Feature Request document
• Triaged by the BAD Lead and Technical Lead and, if possible, “t-shirt size” estimated
• Prioritized by the system’s Business Sponsors to the point where it is high enough on the Product Backlog to progress to the Define phase.

At this stage, however, the feature is still merely a request, an idea. The idea may be good or it may be bad. There might be a better way of achieving the underlying business objective. It might be that the feature is best split into phases. All of this is yet to be discovered.

Step 2.1 – Identify Stakeholders

The first step in the Define phase is to work out who will be involved. There are three key stakeholders in any given feature:

• Business Analyst Designer (BAD) – if there are multiple BADs on the team, the BAD Lead nominates one of the BADs to own the feature, at least for the Define phase.
• Business Owner – a single person who represents the business for the feature, and is nominated by the Business Sponsor. This needs to be someone from the business who knows, in detail, what the business is trying achieve. It is not necessarily the same person that requested the feature. The challenge is finding someone who is senior enough to be empowered to make sensible decisions on behalf of the business, but not so senior that they don’t know the detail and are never available.
• Technical Owner – a single person from the technical team who participates actively in the design process and is responsible for ensuring the design is technically feasible. They are also responsible for estimating costs in Step 2.5.

The Business Analyst Designer, Business Owner and Technical Owner work together (i.e. collaborate) on the design, as illustrated in the following diagram:

The diagram also shows three supporting roles – Business Sponsor, Business Analyst Designer Lead and Technical Lead. These act as escalation points for the key participants, also perform approval roles later in the process.

Note that the collaboration model is distinctly different from the “requirements gathering” approach, whereby a Business Analyst works with business users to “gather requirements” and then separately with the technical team to design a “solution” to meet the “requirements”. In BADM, the two activities are melded into a single, collaborative activity. That’s not to say that the Business Analyst Designer won’t have separate sessions with either the Business Owner or the Technical Owner. Often the BAD flip-flops between the two of them – discussing business concepts with the former, then technical constraints with the latter – until eventually the design comes together. The key point is that the output is a design which all 3 participants agree on and own together.

In many cases, the Business Owner needs help from other people in the business. In BADM these are referred to as subject matter experts, or SMEs. There can be any number of SMEs participating in the design, but the Business Owner is ultimately responsible. The BAD should work with the Business Owner to identify who the relevant SMEs are and make sure they are involved.

In summary then:

1. The BAD Lead nominates the Business Analyst Designer
2. The Business Sponsor nominates the Business Owner
3. The Technical Lead nominates the Technical Owner
4. The Business Analyst Designer works with the Business Owner to identify business SMEs

Once the participants are identified, the Business Analyst Designer adds their names to the Product Backlog.

This is also a good time to start the Feature Scope Definition. The Feature Scope Definition (FSD for short) is a slide deck presenting the opportunity space, all design options considered and the option selected, as well as its estimated size, and is the main output of the Define phase.

For the sake of speed and consistency, there is a Feature Scope Definition template. The structure of the template closely follows the sequence of steps in the Define Phase.

At this stage, the title page and the “Stakeholders” page can be completed. Once created, the FSD is saved in the following location on the team’s shared drive:

• Features/<Feature ID> – <Feature Name>/02 Feature Scope Definition/<System Name> FSD – <Feature ID> – <Feature Name> v1 WIP.doc

For example:

• Features/F001 – Choose Delivery Address at Checkout/01 Feature Scope Definition/System X FSD – F001 – Choose Delivery Address at Checkout v1 WIP.doc

The document is version controlled. The version numbers are integers – there is no distinction between draft versions and approved versions. Approval is signified by names and dates on the last slide. Also note that the “WIP” suffix indicates that the document that has just been saved is not yet version 1 – it is a Work In Progress – working towards version 1. For more details on version control, see this article.

Step 2.2 – Understand Opportunity Space

It’s very tempting as a Business Analyst Designer to start out by asking the Business Owner:

What change do you want to make?

That’s an important question, but before it is asked, it is important first to understand the opportunity space – the “as is” for the part of the business that someone wants to change. So a much better first question is:

Tell me how you do things currently.

Shortly followed by:

Why do you want to change things?

And, most importantly:

What benefit do you think the business will get from changing things?

It’s difficult to underestimate the importance of asking these three questions. All too often a proposed change seems sensible on the surface, but often it is only one possible option of many which would all achieve (or partly achieve) the same objective and deliver (or partly deliver) the same benefit.

This step is sometimes referred to as “understanding the underlying business need”. I agree with the intent of this phrase but I don’t like the specific terms used – it implies that something is truly needed, whereas in fact all change is optional. See this article for a deeper discussion.

Likewise, people sometimes talk about understanding the “problem space”. Again, I’m not too keen on the word “problem” because it implies that something needs to be fixed, and that there is no option to leave things as they are. Whereas in fact, what is, just is. Calling it a problem is merely a label. What’s important is whether it is beneficial to make a change. If the cost of making a change outweighs the benefit, then it might better to leave things as they are. Hence I prefer to talk about opportunities rather than problems.

Once the opportunity space is understood, the Business Analyst Designer captures it in the FSD. He draws one or more diagrams of the “as-is” situation and annotates the diagram to highlight the aspects of the as-is that could potentially be improved. This takes as many slides as it takes. As ever, pictures are generally better than words. Here’s an example opportunity space diagram:

Step 2.3 – Identify Options

Once the opportunity space is well understood, the team can then start thinking about different ways to achieve the stated objective.

Without even thinking, there are likely to be two options on the table already:

1. The idea that the requester came up with originally (unless the requester really has no idea on how the “fix” a perceived “problem”)
2. Do nothing

The “do nothing” option is always worth including, just to remind the team that there really is an option to not proceed. It’s all too easy to get caught up in design, to the point where the design has got so complex that it’s going to cost way more than it’s worth. The “do nothing” option reminds the team to check that it really is worth proceeding.

The next thing to consider is whether there is a “manual workaround”. Most features involve adding a capability to an IT system to achieve some business objective. Often the Business Owner says “the system needs to do X” without really thinking about whether X really needs to be done automatically by the system. Sometimes the business objective can be achieved via some manual process, or “workaround”. This is often a good option if the opportunity space involves dealing with a edge case – something that doesn’t happen very often.

For example, let’s say an online store uses a postcode-based address lookup. When new postcodes are issued (in the UK) sometimes they are not in the lookup database, and the lookup fails. But it doesn’t happen very often. Probably the Business Owner has asked that the online store has a manual address entry capability. And if the web store has millions of customers, this is probably a good idea. But if the number of customers is small, a manual workaround would be to add a message to the screen saying, “if you can’t find our address, give us a call and we’ll take your order over the phone”. Quicker to deliver, and possibly a good interim solution. That’s not an especially good example, but you get the idea.

After that, things get more tricky. The team needs to generate as many ideas as possible, and this is where creative thinking comes in. There are a whole host of techniques for generating ideas. Here are some of my favourites:

• Hold a workshop with all relevant participants
• Make some tea, sit down and think
• Go for a run
• Take a bath
• Do pretty much anything other than think about the problem, and an idea will come to you when you’re least expecting it 🙂

When running workshops, I’ve found that a good way to do it is to present the work-in-progress FSD – especially the “as-is” diagrams, and then put up the “options” slide, including any options already identified. This tends to get people thinking about what other options there might be.

There are often several options which are all variations on a theme, for example, “do X”, “do Y”, “do X and Y”. It’s a good idea to capture each of these as separate options, because you can then get them all costed separately and make useful cost/benefit trade-off decisions on the variations. This is especially useful for “nice to have” optional extras – the tendency is to include them without thinking about the cost. Putting them as options forces the team to think about whether they are really worth it.

As options are identified, the Business Analyst Designer adds them to the FSD. For each option, the following information is added:

• Overview of the option – ideally a copy of the “as-is” diagram from step 2.2, amended to show how the option changes things
• Further details (can be done as bullet points on a separate slide)
• Pros and cons

At this stage, we are not selecting a preferred option – that comes in step 2.6, and we have a couple more things to do first.

You can read more about this activity in the separate article on options engineering.

Step 2.4 – Identify Phases

I really can’t emphasise the importance of this step enough. Here’s why.

When designing software, the participants (including the BAD) have a tendency to come up with all sorts of ideas (good and bad) about matters of detail. People are by nature creative and they just can’t help having ideas. The natural tendency is to include all the ideas in the scope of the feature, especially if they are good ones, even if they are not absolutely necessary to achieve the stated business objective.

The trouble is that this bloats the size of the feature so it takes longer, and costs more, to deliver.

The simplistic answer to this is to ensure that the scope of the feature is kept to a bare minimum – only deliver what is absolutely necessary to achieve the business objective, and say “no” to everything else. But of course it’s never quite as simple as that. In my experience, Business Owners (and, to some extent, Business Analyst Designers) find it extremely difficult to say “no” to a good idea, especially if it’s an idea they had themselves. They will tend to insist that their idea is essential when really it’s not. This is especially true if it feels like it’s “now or never”.

So the Business Analyst Designer plays a psychological trick. He splits the feature into two phases. Rather than saying “yes” or “no” to any given idea, the Business Owner now has to choose whether to deliver it in phase 1 or phase 2. Phase 1 is to contain the bare minimum to achieve the business benefit (or even some subset of it), to be delivered ASAP, and phase 2 is “everything else”, to be delivered “later”. This turns out to be a much easier decision to make, because nothing is ever rejected, it is merely prioritised.

This is such a simple trick and yet I have found it to be immensely powerful. It allows the whole team to focus their energies in the most important aspects of the feature and avoid getting distracted by “nice to have” aspects.

Ah, you might say, but surely Phase 2 never gets delivered, because all it contains is a bunch of ideas which are “nice to have” with no hard business benefit. It will never make its way to the top of the Product Backlog, because there will always be something more important to do.

And you’d be absolutely right! That’s precisely the effect we’re looking for. We’re looking to avoid (or at the very least, delay) the delivery of low value capabilities. When I hear that argument from Business Owners, I always reply that we will deliver it just as soon as it’s the most important thing on the Product Backlog. Often, we both know that means never, but it’s a difficult position to argue against.

So, the Business Analyst Designer always looks to split a feature into at least two phases. In some cases, there might be three or more phases, but in most cases it’s enough to have two – the important stuff and “everything else”. If and when the “everything else” feature gets into its own Define phase, it can be further split down if necessary.

There is an exception to this rule. Some features are already so small that there is no way to split them down any further – for example when a feature is an alteration to the behaviour of an existing capability (like removing an obsolete field from a data entry screen).

Note that phasing needs to be applied to each option – the key point being to work out what “phase 1” of each option looks like, because that’s what gets costed up in the next step.

Once the phases have been defined, new features are added to the Product Backlog as appropriate. The existing feature becomes phase 1 and new features are added for phase 2, 3 etc. The new features stand as features in their own right and start the BADM process from the beginning again (Phase 1 – Request). When creating the new features, the BAD has the option of giving them new sequential numbers or adding a letter suffix. For example:

• F187 – Purge & Reload

Could either become:

• F187 – Purge & Reload Phase 1
• F254 – Purge & Reload Phase 2 (the next available feature ID)
• F255 – Purge & Reload Phase 3

Or it could become:

• F187a – Purge & Reload Phase 1
• F187b – Purge & Reload Phase 2
• F187c – Purge & Reload Phase 3

The benefit of the latter is it gives better traceability to business stakeholders and avoids confusion over the fact that F187 started out as being the full scope of “Purge & Reload” but then became only a subset of the original scope. But you do have to deal with the fact that you no longer have nice integer feature numbers – probably a small price to pay.

Feature splitting quite an art – it’s hard to get right and it takes practice. I’ve written a separate article called How to Split User Stories that goes through the technique in way more detail.

Step 2.5 – Estimate Costs

Once the team has identified as many options as it can, and worked out what phase 1 looks like for each option, it’s time to work out how much each option would cost to deliver.

It’s important to do this before selecting a preferred option. In the absence of costs, the team is likely to pick the option that gives the best overall capability. But that is also likely to cost the most. Estimating the cost allows the team to make a trade off between cost and quality.

Estimates are the responsibility of the Technical Owner. This is important because he is the one who has to commit to delivering the feature. Also, he is in the best position to know the true delivery effort.

Estimates are done in Feature Points (FPs), which are analogous to story points in XP. They are an estimate of the effort required to code and test the feature, including the effort required to fix defects. The unit of measure is somewhat arbitrary, but it’s common to estimate on the basis of one FP = one “perfect” (i.e. uninterrupted) day of coding or testing. My current team uses the ratio of one FP = two man-days. It doesn’t matter as long as feature points are consistent across features. Over time, the team learns its “velocity”, just as in XP/Scrum.

There’s an important difference between BADM and XP/Scrum here. In XP/Scrum, the team tends to estimate the story points for a story based on a brief conversation with the Product Owner. At this point there has usually been no, or very little, analysis of the underlying business objective or any consideration of possible design options. Whereas in BADM, the team has already done quite a lot of thinking about what is to be delivered. BADM feature point estimates are therefore generally more accurate than XP/Scrum story point estimates.

Once the Technical Owner has provided the Feature Point estimate for each option, the Business Analyst Designer adds them to the FSD.

Step 2.6 – Agree Scope

Finally, armed with the various options and phases, and the pros, cons and costs of each option, the team decides on the preferred option. Usually by this point, everyone secretly (or not so secretly) knows which option they prefer already. Sometimes, however, the cost estimates are not as expected, and opinions have to be altered.

So, in this step, the participants meet, view the presentation together, and agree the preferred option. The Business Analyst Designer updates the FSD to capture the decision there and then in the meeting. He also updates the “approval” slide at the end of the FSD, to confirm who has made the decision and on what date.

In particular, the FSD is approved by:

• Business Owner
• Business Analyst Designer Lead
• Technical Lead

Note that the Business Owner has sole power of approval from a business perspective. It is their responsibility to ensure that all other SMEs accept the preferred option.

Just to re-iterate, approval is done face-to-face in a meeting, with the FSD being circulated for information afterwards (effectively acting as the minutes of the meeting). It’s tempting to have the meeting and then send the FSD out for review/approval afterwards. Resist this temptation. It causes procrastination and slows the whole process down. If any of the approvers refuses to approve the FSD in the meeting, assign actions as necessary and then meet again (maybe just with that person) to complete the approval process.

The point here is that we’re trying to keep the process as lightweight as possible. We capture the design without getting too tied down in documentation process.

Step 2.7 – Re-Prioritize Feature

The feature was originally prioritized in the Request phase, at a point where we didn’t really know what it was. That initial prioritization was done based on the best information at the time. Now that we have completed the Define phase, we know more about the costs and benefits of the feature, and it makes sense to re-visit the priority. Clearly the feature is already a high priority or it wouldn’t be being worked on, so the main question is: “is it still a high priority”? Have we discovered something that has either eroded the benefits case or significantly increased the costs? If so, it’s worth moving the feature down the priority list (i.e. down the Product Backlog).

An extreme version of moving a feature down the backlog is to completely withdraw it. This occurs when it is decided that the benefits do not outweigh the costs and it is not worth delivering. Put another way, the team has selected the “do nothing” option. There is a separate tab on the Product Backlog for withdrawn features. Withdrawing a feature is simply a matter of moving the feature to the Withdrawn tab and adding a note to the “Reason for Withdrawal” column to explain why.

Phase 2 Outputs

The outputs of the Define phase are:

• A completed Feature Scope Definition, including…
• The opportunity space (context/as-is)
• The design options, each with pros, cons and cost (feature point estimate)
• Phases defined, where appropriate
• The selected option

To give an idea of what a completed Feature Scope Definition looks like, I’ve included an example FSD.

Next Steps

Once the Design phase is complete, in most cases the feature proceeds directly to Phase 3 – the Design phase. However, if the feature has been de-prioritized, it might return to the product backlog for a period of time. Obviously, if it has been withdrawn then there is nothing further to do.

Also, once the feature has completed the Define phase, its size is known, and it is thus possible to allocate it to an increment for delivery. Alternatively, you can wait until the Design phase is complete (just in case it throws up any nasties which significantly affect the size).