This article provides a detailed description of Phase 1 of the Business Analyst Designer Method – Request.

Overview

The Request phase is all about getting a feature requested, logged and prioritized for further work.

The following diagram illustrates the outputs of the Request phase (there are no inputs):

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

Step 1.1 – Request Change

In this step, somebody requests a business change. When I say “business change”, I am usually talking about an IT system change, but in the general case, someone is requesting a change to the way the business works.

Anybody can request a business change, including:

• Business sponsor
• Business user
• Customer
• Business analyst designer
• Technical team member
• Tester
• Bloke down pub 🙂

OK, maybe not the last one, but you get the gist. The point is that anyone can have an idea, and often the best ideas come from people who aren’t official stakeholders. Technical team members and testers involved in the detail of the system often come up with suggestions for improvement.

Someone wanting to request a change does so by communicating their request with the Business Analyst Designer Lead. Any form of communication is allowed, including:

• In person, in a workshop
• In person, at the water cooler
• In person, at the Business Analyst Designer Lead’s desk
• By phone
• By email
• By carrier pigeon 🙂

The key point is that there is no intimidating change request form to complete. Well, there is (see Step 1.3 below), but the requester does not fill it out themselves. All they have to do is communicate the change and the Business Analyst Designer Lead does the rest.

Another important point is that the requester might not even know what change they want at this stage. They might only know that there is an opportunity for a change. That there is some aspect of the business that would benefit from a change. Often they describe a “problem” that “needs fixing”.

Step 1.2 – Create Feature

In this step, the Business Analyst Designer Lead creates a feature for the change request and lets the requester know.

In BADM, the feature is the unit of delivery. It is roughly equivalent to a user story in Scrum/XP. Each feature evolves throughout the process, starting as a request, and ending up as fully designed and ready to build. Features can also be split, merged and withdrawn during the process.

Creating a feature simply involves adding it to the Product Backlog. The Product Backlog is a spreadsheet which lives on a shared file store somewhere that everyone can access. It lives in a folder called “Features” which will also hold all documentation for each feature.

For your convenience and delight, I have provided a Product Backlog template.

The Product Backlog has one row for each feature, so creating a feature means adding a new row to the spreadsheet. There are many columns on the Product Backlog, but the only ones that are filled in now are:

• Feature ID
• Feature Name
• Description
• Benefit/Objective (optional)
• Status
• Requester

Feature ID is unique and is used for tracking purposes. This is useful as a shorthand and also because the feature name can sometimes change as more is discovered about the feature. The format is “Fnnn”, where nnn is a sequential number, left padded with leading zeroes i.e. F001, F002, F003 etc. The leading zeroes are useful for ensuring your feature folders appear in order when organised alphabetically (e.g. on a file system). For organisations with multiple product backlogs, a prefix can be used for disambiguation e.g. SYSX-F001.

Given that features very quickly get prioritized out of sequence, it is useful to keep a surplus of rows at the bottom of the product backlog with the next few available Feature IDs already filled in.

Getting Feature Name right is important. Features are most commonly referred to by their ID and name, and so it’s useful to choose a name that all stakeholders are able to understand. Also, it’s OK to change the feature name at any point – sometimes a feature starts out life as one thing and then evolves into something very different (e.g. a different way of achieving the same underlying objective).

Description is a single paragraph summary of the feature – enough detail to act as a reminder as to the scope of the feature. At this stage, the Business Analyst Designer Lead might not actually know the scope of the feature, only what has been requested, so they have to write something that summarises the request. In some cases this might only be a vague statement of a “problem” that “needs fixing” e.g. “Fix the multiple addresses problem”. The description can be updated later when it is known how the problem will actually be fixed e.g. “Fix the multiple addresses problem by allowing the customer to choose a delivery address at checkout”.

Benefit/Objective is a one paragraph summary which can be filled in if it is clear at this stage. Sometimes the underlying objective isn’t discovered until Phase 2.

Status at this point is “Requested”.

Finally, the Business Analyst Designer Lead closes the loop with the requester by letting them know that a feature has been created for their request and that it will be “looked at” in due course. This is normally done by email, including a cut & paste of the relevant row from the Product Backlog. Importantly, the Business Analyst Designer Lead tells the requester the Feature ID, so they have a unique reference they can use to check up on progress. Sending the requester the Feature ID is surprisingly powerful. It tells them that their request has been heard, logged and has entered some form of official process.

An important property of the method is that it is quick and easy for anyone to request a change, up to the point where the request is logged and given a unique tracking number. Of course, creating a feature offers absolutely no guarantee of anything being delivered in any reasonable timeframe, but it is very comforting to know they have been listened to!

Step 1.3 – Document Feature Request

In this (optional) step, the Business Analyst Designer Lead writes down further details about the requested change.

This step is optional but strongly recommended. Its purpose is to capture an account of the requested change whilst it is still fresh in the mind. It is particularly useful on larger projects where there is a team of Business Analyst Designers.

The act of writing down the requested change also forces the Business Analyst Designer Lead to start the process of thinking about the request. I find then when I put pen to paper, I am forced to organise my thoughts, and this often results in insights into the problem at hand.

For the sake of consistency and speed, there is a Feature Request template. At this stage, three sections are completed:

• Feature ID
• Requester (name and, if appropriate, contact details)
• Description of request

Importantly, this is a description of what has been requested, without much (if any) processing.

If the change request was received by email, it is perfectly OK to cut & paste the body of the email (or embed the email itself) – whatever is quickest. There are no points for style, and speed is of the essence.

Once created, the Feature Request is saved in the following location:

• Features/<Feature ID> – <Feature Name>/01 Feature Request/<System Name> Feature Request – <Feature ID>.doc

For example:

• Features/F001 – Choose Delivery Address at Checkout/01 Feature Request/System X Feature Request – F001.doc

The Feature Request is not version controlled.

To give you an idea of what feature requests can look like, I’ve provided a ZIP file containing a few example Feature Requests.

Step 1.4 – Triage Feature

In this step, the Business Analyst Designer Lead and Technical Lead together perform a brief assessment of the feature to determine, if possible, its approximate size.

This is intended to be a very quick assessment (max 10 minutes) based on the information to hand, and the output is a very rough estimate of the net effort to design, build and test the feature, excluding any management/release overheads. The purpose of the rough estimate is to help business sponsors prioritize the feature relative to other features.

The estimate is done as a t-shirt size (S for small, M for medium, L for large, XL for extra large etc.), where each size represents a range in man-days. The ranges depend on circumstances, but here’s an example I have used in the past on a large project:

• XS: 0-5 man-days
• S: 6-25 man-days
• M: 26-50 man-days
• L: 51-100 man-days
• XL: 101-200 man-days
• XXL: 201-400 man-days

In some cases, there is significant ambiguity surrounding a feature, to the point where a size estimate is not possible. I have been told in the past that we need to “replace X”, without having even an inkling as to what X is. In such cases, the most honest size estimate to give is “unknown”. This is more accurate than putting “XXL”, which is misleading and can result in features being withdrawn unnecessarily.

It is tempting at this point to spend some time investigating the requested feature to get enough detail for a size estimate. Usually this temptation is better resisted until after the next step (prioritization) because if the feature is given a low priority, any time spent is potentially wasted.

The Business Analyst Designer Lead does two things to capture the output of this step:

• Adds the t-shirt size estimate to the Product Backlog
• Optionally, completes the “Triage Comments” section of the Change Request with any notes from the discussion with the Technical Lead e.g. early ideas on design options for the feature

This step can be done on an ad-hoc basis or via a regular meeting between the Business Analyst Designer Lead and the Technical Lead (e.g. weekly).

Step 1.5 – Prioritize Feature

In this step, the Business Analyst Designer Lead identifies a business sponsor for the feature and works with all relevant business sponsors to prioritize the feature.

Given that anyone can request a feature, it is very important to identify a business sponsor for the feature. For a given IT system, there is a defined set of business sponsors, and only someone on the list can sponsor a feature. For some systems there is only one sponsor, for others there are many. The sponsors are typically senior business people who control budgets i.e. they are paying for the work.

The Business Analyst Designer Lead convenes a meeting of the business sponsors to allocate and prioritize the feature. Given that business sponsors are generally busy people, it’s a good idea to do several features at a time and/or hold a regular meeting (e.g. weekly), which can also be used to give progress updates on other features in flight. One option is to have it as an agenda item on a regular project steering group meeting.

The Business Analyst Designer Lead explains the new feature – who has requested it, what the potential benefits are and the size estimate if known. Given this information, a sponsor is identified. If nobody wants to sponsor the feature, it is withdrawn (unless it needs to be deferred for further investigation or for some other reason).

The feature is then prioritized relative to all other features on the product backlog. This has to be done with all business sponsors present so that a consensus is achieved.

In my experience, prioritization is hard – very hard. Nobody likes to do it, and it often involves making difficult choices based on not enough information. Each business sponsor has their own priorities. Large, high value features must be traded against small, low value features. There are often complex interdependencies between features. Some features are low value but carry architectural risk.

Doing prioritization well is also very important. It will never be perfect, but it needs to be as good as possible in order to make sure the team is working on the right things at the right time.

My favourite technique for prioritizing features is to use index cards. I lay them out on a table and get the participants to stack rank them – in the order they would like them delivered. I avoid using labels like “must”, “should” and “could” – I just get them ordered from “first” to “last”.

One of the hardest challenges is trading off large, high value features against small, low value features (“quick wins”). The tendency is to put all the high value features at the top of the list at the expense of the “quick wins”. I try to make sure that at least some quick wins bubble to the top of the list, otherwise you end up with a system that has lots of niggly issues that, individually, are no great problem but collectively tend to erode user confidence in the system.

There’s way more to say on the art of prioritization, but I’ll save that for a dedicated article.

Outputs

The outputs of the Request phase are:

• The Product Backlog, with the new feature added, t-shirt sized and prioritized
• Optionally, a Feature Request containing further details on the requested change, and any notes from the triage session

Next Steps

Once the Request phase is complete, it is likely that the feature will sit on the product backlog for a period of time. If the feature is a very low priority, it is possible it will sit on the product backlog indefinitely. This is absolutely the outcome we are looking for – avoiding doing low value work.

When (if) the feature does rise to the top of the product backlog, it is by definition the next most important feature to start further work on. At this point, Phase 2 (the Define phase) commences for the feature.