James Cadle Business Analysis Techniques: 72 Essential Tools for Success

Подождите немного. Документ загружается.

172

Working in small teams at an oﬀ-site location, the participants create and

demonstrate prototype solutions to business problems, which are judged by

their peers each day. Sometimes this may involve diﬀerent teams competing

with each other to produce the best overall solution. In this case, a winning

prototype is chosen to be taken forward into full development at the end of the

event.

Hothouses are eﬀectively Agile prototyping workshops that closely map

development to customer needs, signiﬁcantly increasing the quality of solutions

while shortening delivery timescales.

Hothousing is used to ensure a shared understanding of the business problems

and deﬁne working solutions that will be delivered in a subsequent ﬁxed release

cycle (timebox) of, say, 90 days, with business beneﬁts quantiﬁable in customer

terms. The outcome of the initial hothouse session itself is a mixture of prototypes,

processes, priorities, cost–beneﬁt analyses and metrics. It is common for this

three-day period to involve a number of teams producing competing prototypes,

with one of these being selected to progress forward to full delivery.

While the actual structure of this three-day hothousing session will vary, the

general approach is as follows.

Day One focuses on presenting and understanding the business problem,

with each team developing a high-level outline of how they would solve it.

At the end of the day each team summarises its proposed approach. Some

form of scoring and ranking takes place, and the teams are left to reﬂect on

their eﬀorts overnight, ready to begin Day Two with a modiﬁed approach if

appropriate.

On Day Two each team develops a prototype version of their solution to

the problem, based on the approach outlined on Day One. For this to work

successfully they will need access to business users and domain experts as

appropriate. By the end of Day Two each team should have produced a

working prototype that can be demonstrated to all concerned. Again,

feedback and scoring is undertaken.

Day Three is primarily a ﬁne-tuning exercise, and after this is completed the

ﬁnal evaluation takes place and the ‘winning’ team is given the opportunity to

turn its prototype into a fully speciﬁed and documented working product

ready for release.

Each hothouse session establishes a post-implementation review (PIR)

‘handshake’. This PIR handshake ensures that all participants (IT and its

customer) have identiﬁed what must be done to achieve customer and commercial

success over the next 90-day period (timebox), and that there are clearly

measurable targets and objectives. The handshake can then be formalised and

captured in a 90-day measures and targets document, which forms the basis

by which the programme’s achievements can be assessed at the end of the

subsequent timebox cycle.

BUSINESS ANALYSIS TECHNIQUES

173

The technique of hothousing can be summarised as:

Transport a group of IT staﬀ and business users to an oﬀ-site location. Have

them stay overnight. Provide accommodation, laptops, a network, a handful

of servers, ﬂipcharts, a presentation room – and unlimited food and drink.

Have teams compete over the course of three days to build a real IT system

speciﬁed by the business. Reward the winning team.

Hothouses are about bringing together the delivery community, and focusing on

the understanding of a business problem. Hothousing can be used as the ﬁrst

stage of an Agile development approach. It emphasises:

common understanding;

building a realisation of the solution;

using competition (between teams) and intensity (long hours, frequent

deliveries) to instil a sense of urgency.

Hothousing was ﬁrst proven in retail environments, and has since been deployed

successfully across a range of sectors and organisation types. The secret of using

it successfully is to unleash the creative powers of those who know the business

best, supported by experienced coaches, skilled facilitators and motivated

implementers. With eﬀective hothousing, teams get swiftly into their creative

stride, implement ideas quickly, evaluate eﬀectively, prove concepts and identify

areas for improvement – and then iterate. The result is fast-paced, highly

productive, high-speed evolution leading to optimal business solutions.

REQUIREMENTS ANALYSIS

Technique 54: Timeboxing

Overview

Timeboxing is one of the most important and yet most misunderstood techniques

available to the business analyst (and anyone else who has anything to do in a

DEFINE REQUIREMENTS

Hothouse

session

Use case

scenarios

Business

problems

– PIR ‘handshake’

(measurable target

and objectives)

– CBA

– Metrics

Chosen

prototype

Measure against

PIR ‘handshake’

Business benefits

Working solution

90-day release cycle

(timebox)

Figure 6.2 Hothousing process

174

ﬁxed or tight timescale). It does, however, have the advantage of being particularly

simple to perform, if it is approached in the right way and with the right mindset.

In many ways its success is as much about having the right mindset as it is to do

with using the technique itself. All involved stakeholders need to buy into the

concept of timeboxing and into an agreement about the proposed timescale of the

timebox itself.

This section provides guidance on how to use the technique in an eﬀective way.

Without eﬀective timeboxing, focus can be lost and things will run out control.

Much of what is discussed here is to do with planning, control and keeping a clear

focus on what actually has to be delivered at the end of the timebox. It is for this

reason that there is a very close relationship between timeboxing and the clear

prioritisation of deliverables. In addition to this, there is also an important reliance

on an ability to estimate the complexity and duration of the tasks to be undertaken.

It is also vital that whoever is actually undertaking the work within the timebox

should be involved in the development of these estimates.

Description of the technique

There are many deﬁnitions of a timebox. Here we will distinguish between two

main types.

An outer or overall timebox is the time between the start and end dates of a

project, or a major stage, or the date on which a major set of deliverables are due.

As a technique, timeboxing is most signiﬁcant when the end date is not movable.

Inner or lower-level timeboxes are nested, like Russian dolls (quite appropriate

when used in conjunction with the MoSCoW approach to prioritisation, Technique

55) or wheels within wheels within the overall timebox, to provide a series of ﬁxed

times by which interim products are to be delivered or partially produced. This

leads us to consider carefully the interrelationships between the various inner

timeboxes in terms of their dependencies and overlaps.

BUSINESS ANALYSIS TECHNIQUES

Inner timeboxes

Outer timebox

Figure 6.3 Outer and inner timeboxes

175

Timeboxing (of both the outer and the inner types) means setting a deadline

or agreeing a time by which an objective can be met or speciﬁc products be

delivered, rather than describing when a task must be completed.

This approach allows us to refocus our eﬀorts on the development of the required

deliverables rather that constantly watching the clock or calendar. Any timebox, at

any level, must therefore have an agreed scope and clear objectives based on a

high-level deﬁnition of what needs to be delivered. It is also important to be aware

(particularly for inner timeboxes) that the focus should be to produce something,

leaving the details of how that thing is actually made to the people doing the

work – assuming that standards and procedures are followed. This makes

timeboxing a product – rather than activity-based technique.

Using timeboxing

The timeboxing technique can be used for the production of any time-critical

deliverables, and is particularly useful where the timescale itself is a critical

aspect of the delivery.

Sometimes people use the phrase ‘Let’s timebox this now’ when they are running

out of time to do something. This usually means they ignore the key aspects of the

technique such as objective setting, estimating, planning, obtaining consensus and

prioritisation. That approach should always be avoided.

Each of the inner timeboxes, which may themselves be nested, will produce a

visible set of deliverables. At the end of the timebox these can be assessed for

completeness and quality before being used as input to the subsequent timebox,

and used to decide whether any of the future timeboxes will need to be replanned.

Inner timeboxes should be kept reasonably short, to make it easier to calculate

what is likely to be capable of being achieved within the speciﬁed time with the

resources available. This means that the technique of timeboxing is not only good

for controlling various components of the business analysis process, but can also

be useful in estimating the resources that will be required to deliver speciﬁc

products such as a requirement document or a business case.

On completion of a timebox, whatever has been delivered usually undergoes an

additional review by those who are going to use the product. If at some point it

becomes apparent that the agreed completion time may be missed, then the

deliverable set should be reduced in scope rather than letting this happen,

otherwise the knock-on eﬀect on other timeboxes may be problematic. The

technique of prioritisation will usually help signiﬁcantly in ensuring that this can

be handled successfully, and may lead to replanning of subsequent timeboxes. For

the eﬀective use of this technique, it is always better to stop the timebox at the

agreed time, review the actual progress, and then perhaps instigate a new

timebox or move some things from one into another, rather that letting any

individual one slip without action beyond its agreed time. In other words, the

philosophy is that scope slips but timing never does. This approach ensures

DEFINE REQUIREMENTS

Some proponents of timeboxing prefer to avoid the word ‘deadline’ when describing the technique: this can create

the wrong impression, since a timebox is often an agreed or negotiated delivery date rather than one that has been

imposed without discussion.

176

timely and frequent delivery of individual products, and ultimately results in the

successful delivery of the ﬁnal products of the outer timebox. However, although

it provides greater control, it is worth being aware that this does result in more

intense working patterns.

While with careful planning it is possible to undertake parallel timeboxes, it is

important to note that a subsequent timebox which involves dependent work

cannot normally be started before any previous ones are complete. This is

because, until an individual timebox has actually been completed, there will be no

guarantee as to the actual coverage of what is delivered. This is particularly true

when this technique is used in conjunction with a formal approach to

prioritisation such as MoSCoW (Technique 55).

All timeboxes, outer ones and inner ones at all levels, should follow certain

general principles in terms of structure, content and resourcing. These include:

Structure and All timeboxes should begin with a planning or kick-oﬀ

content: component and end with a timeboxed review or close-out

component. In between it is good practice to nest inner

timeboxes covering initial investigation, reﬁnement and

consolidation activities. Each of these three activities should

also have their own individual planning and review elements.

Resourcing: When a timebox commences, all the required resources to

achieve the objective should be in place. These include people,

any appropriate technology required, inputs from previous

timeboxes, a prioritised list of what need to be achieved in the

timebox (using MoSCoW, Technique 55), a clear deﬁnition of

the objectives and timescale imposed, and any other facilities

needed. This should enable, whenever possible, the timebox to

be self contained. It sometimes helps to envisage the timebox

as having a lid, which closes when it kicks oﬀ and doesn’t

open again until it is completed except when exceptional

circumstances occur (such as the delivery of the ‘Must haves’

being in jeopardy).

By keeping each individual inner timebox reasonably short, it is possible to let it

take place relatively undisturbed until completion, and only then to assess the

impact on subsequent timeboxes in the light of what has actually been delivered.

Technique 55: MoSCoW prioritisation

Description of the technique

Usually there is a constraint on the time or budget available to undertake a piece of

work, and not everything can be done at once or even at all. As a result some form

of prioritisation is vital. The problem is that, despite these facts, prioritisation is not

always done well. This is partly because consensus on what is most important is

not always easy to achieve. Because there are interrelationships and dependencies

between discrete requirements, and because things change constantly throughout

projects, a re-evaluation of priorities already agreed on is required. However, the

BUSINESS ANALYSIS TECHNIQUES

177

main reason for problems with prioritisation is the lack of agreed standard

deﬁnitions as to what various priorities mean, and of clear procedures as to

what to do when these priorities change.

This section uses an approach to prioritisation based on a concept called

‘MoSCoW’. It proposes some speciﬁc meanings for the terms used in this approach,

and identiﬁes some guidance that overcomes some of the most common diﬃculties

that occur with its application in practice. The technique described here is of

particular use when timeboxes are ﬁxed and when it is possible to deliver products

incrementally rather than in a one-oﬀ release covering everything. In all cases it is

vital to ensure that all essential work is done ﬁrst, with less critical work being

delayed until later or omitted altogether if appropriate.

The MoSCoW rules are employed to help achieve clear prioritisation of

requirements. The ‘o’s in the acronym have no meaning. The remaining

components of ‘MoSCoW’ as used in this chapter are deﬁned here.

Must have: These are requirements that are fundamental (they are

sometimes also referred to as the ‘Minimum usable subset’).

Without them, the deliverable will be unworkable and useless.

Their delivery at the end of the appropriate timebox is

guaranteed (it is speciﬁcally because of this guarantee that

much eﬀort should be employed to ensure that the list of Ms is

kept as small as possible, and that sensible estimates of the

time at which they can be ready are agreed). If any one of these

‘Must haves’ is not ready then nothing can be released: if it

could be, then they were not really ‘Must haves’ in the ﬁrst

place. As a result of this, it is important to be aware that the

term ‘Must have’ covers the functionality itself, its legality and

DEFINE REQUIREMENTS

Timebox planning

(kick-off)

Investigate

15%

Refine

70%

Consolidate

15%

Timebox review

(close-out)

Figure 6.4 Example of the structure of a typical timebox

178

its level of quality. It is for this reason that things can usually

only be prioritised properly once a certain level of decomposition

and deﬁnition of the requirements has been achieved.

Should have: These are important requirements for which there is a

work-around in the short term, or where expectations can be

managed. They are things that would have normally have been

classiﬁed as ‘Must haves’ in a less time-constrained situation,

but the deliverable will still be useful and usable without them

initially. The mindset of good MoSCoW prioritisation is that one

would normally expect to deliver, in addition to all the ‘Must

haves’, a large proportion of the ‘Should haves’ (but this delivery

is not guaranteed). The ‘Should haves’ are often described as

those things that you would expect to be included within a

product of this type, but whose non-inclusion would not

necessarily delay the release. They would, however, be expected

to be delivered soon afterwards, since the work-around is not

usually a long term solution.

Could have: These are requirements that can more easily be left out at this

point. They may well be included in this delivery if their

inclusion is easy to achieve without jeopardising the delivery

of the ‘Must haves’ and ‘Should haves’. A ‘Could have’ may be

diﬀerentiated from a ‘Should have’ by considering the degree of

pain caused by its non-inclusion in terms of business value or

number of people aﬀected.

Want to have This refers to those valuable requirements that can wait until

but won’t later. It is often useful to keep these in the initial priority list,

have this since, although they are not due for delivery yet, knowledge that

time round they will be coming later may inﬂuence design decisions and the

(or won’t approach taken to the planning of subsequent deliveries.

get yet): Remember, however, that although something is a ‘W’ initially

it will almost certainly get a diﬀerent priority in subsequent

increments (perhaps even an ‘M’ in the next one), and knowing

when it is due to be delivered can be very useful for planning

purposes.

This clear deﬁnition of terms with precise meanings is signiﬁcantly better than

any prioritisation approach that uses numerical values for priorities, or, even

worse, words such as high, medium or low, which do not have a precise meaning

outside a speciﬁc context.

All of the items in the prioritised requirements list (the MoSCoW list) are

due for delivery at some point, although the total delivery may be spread

over a number of increments. The MoSCoW rules provide the basis on which

decisions can be made regarding the whole project, and during any timeboxes

included within the project. It is for this reason that the techniques of

prioritisation and timeboxing are so useful when applied together. The MoSCoW

list is likely to change throughout the project, in terms both of changes to

requirements and of changes to the priorities themselves. For this reason

BUSINESS ANALYSIS TECHNIQUES

179

it is vital that they are subject to well-deﬁned change- and version-control

procedures.

As new requirements arise, or as existing requirements are deﬁned in more detail,

decisions must be made as to how critical they are to success by using these

MoSCoW rules. All priorities should be reviewed throughout to ensure that they

are still valid. It is not appropriate to wait until time is running out, resources are

transferred or conﬂicts occur before starting the prioritisation exercise.

Using MoSCoW prioritisation

It is essential that not everything proposed in a given timebox or project is a

‘Must have’. It is the existence of lower-level priority requirements that allows for

ﬂexibility and agility in dealing with problems that arrive and with the inevitable

change of scope. In fact, experience suggests that if more that 60 per cent of the

estimated time for a piece of work is taken up by ‘Must have’ requirements then

the proposed timescales are unlikely to be met.

Once all stakeholders are clear about the meaning of each of the MoSCoW

priority levels, and there is a published procedure specifying who is allowed to

change priorities, it is much easier to make rapid progress through a project and

to reduce delays when decisions are needed. For example, some organisations

empower team members to adjust the scope of delivery as long as there is no

eﬀect on the delivery of the ‘Must haves’ within their work package, only referring

to a higher authority when the delivery of ‘Must haves’ is at risk or when a

decision is required to drop a ‘Must have’ to a lower priority level. As new

requirements are identiﬁed they can be allocated a priority themselves and take

their rightful place in the stack of requirements, sometimes causing existing

requirements to move further down this list.

When undertaking a prioritisation exercise it is not unusual for there to be

heated discussions as to what priorities should be allocated to various

requirements, and it is particularly common for there to be a very large list of

‘Must haves’. It is important that this situation is addressed early. This can

involve spending some time explaining the speciﬁc meaning of the MoSCoW

levels. People often say ‘M’ when they mean ‘S’, and ‘S’ when they mean ‘C’. (It is

also common for the ‘C’s and ‘W’s to be mixed up). Remember, if a ‘Must have’ is

not delivered on time then neither is anything else! A very good tip to help avoid

this happening is to allocate everything initially as a ‘W’ and work backwards

towards ‘M’, justifying each move.

However, the main reason why there are usually so many ‘M’s is that the

prioritisation is often carried out on requirements that are deﬁned in insuﬃcient

detail. While the high-level deﬁnition of the requirement might suggest a priority

of ‘M’, once decomposed or considered in terms of diﬀerent scenarios it becomes

apparent that there is much that can be categorised as ‘S’, ‘C’ or even ‘W’. In fact

it is this decomposition approach that provides even more ﬂexibility, once various

aspects of a requirement are considered separately in terms of priority.

Consider the following example:

Requirement: to be able to view a customer bank account balance.

DEFINE REQUIREMENTS

180

For any reasonable banking system, this will be an ‘M’ for the ﬁrst release of the

system. However, if it were to be decomposed into its component parts and also

considered from the perspective of various scenarios and extensions, it becomes

clear that there is plenty of scope for some elements to be allocated a lower

priority or left until later without jeopardising the delivery of the basic facility to

customers. It is of course important not to overdo this, and to ensure that enough

is initially oﬀered to the customers for them to be comfortable while waiting for

the remainder of the features to become available.

This approach is even more powerful when applied to the non-functional as well

as the functional aspects of a requirement. So a more detailed deﬁnition of the

requirement might lead to the following use of MoSCoW:

Functional to be able to view a bank account balance – priority M.

requirement:

non-functional

requirements:

security – priority M;

being up to date, to the latest transaction – priority S;

availability in both pounds and Euros – priority C;

availability in various languages – priority C.

This would allow us to deliver a system on time that allowed customers to check

their bank balance; while we would initially expect it to produce totally up-to-date

results, the ﬁrst release might need to put out a message saying that transactions

performed during the current day might not yet be shown. This approach would

also allow the work on currency and language to be carried out with less urgency

and released when it is completely ready and tested, without delaying the initial

key features.

MoSCoW is particularly powerful as a prioritisation technique when used in

conjunction with timeboxing (Technique 54). For example, a requirement that is

an ‘M’ in the overall project might only be an ‘S’ in an early timebox, allowing

it to slip out of that timebox and be delivered later (but still in time for the full

release) rather than delay other early requirements, which may need to be in

place quickly to allow other areas of development to get started. In fact, a

MoSCoW priority for an item is only really meaningful in a speciﬁc timeframe;

items may take on diﬀerent values in other timeframes or lower-level inner

timeboxes.

Technique 56: Requirements organisation

Description of the technique

At its simplest, a requirement is a service, feature or behaviour that the user

wishes the ultimate solution to perform or exhibit. However, once a potential set

of requirements has been identiﬁed, it is vital to organise these before validating

BUSINESS ANALYSIS TECHNIQUES

181

them and using them to derive solutions. This topic of requirements organisation

can be further subdivided into requirements structuring, and requirements

negotiation and conﬂict analysis.

Requirements structuring

Sets of requirements that analysts are dealing with are often big and complex.

This makes the structuring process one of the most important activities in

requirements engineering. How requirements are structured and presented has a

direct impact on the requirements deﬁnition process and on their ultimate quality.

In particular, the analyst should create a clear vision of the way requirements are

being deﬁned, built and presented. This organisation and structuring also helps

with checking the completeness and consistency of the requirements and will

support their subsequent review. In addition, most projects will involve more than

one user and more than one business area. During analysis of the set of

requirements that have been identiﬁed it is important to see if some of them

overlap, or if in fact they form a single high-level requirement when taken

together. Identifying this situation early will make any subsequent structuring

of requirements easier.

When structuring them, it is important to consider both how the overall set of

requirements is organised and how the individual requirements themselves are

structured. Attention should be paid to:

requirements sets and clusters;

links and dependencies between requirements;

levels and hierarchical decomposition of requirements.

Requirements sets and clusters

Within even the most trivial development the number of individual requirements

can quickly become large and unmanageable, particularly when these requirements

are supported by additional models and diagrams providing more detailed

deﬁnitions of business rules and information usage. As a result it is good for

organisations to agree a standard way of grouping similar types of requirements

together within the requirements speciﬁcation. Perhaps the simplest way to

undertake this grouping initially is to cluster the requirements set into the

following high-level groups:

functional requirements (and non-functional requirements that relate only to

speciﬁc individual functional requirements, which could remain here with

their owning functional requirements rather that being kept separately);

non-functional requirements;

general requirements;

technical requirements.

Some organisations may wish to extend this list of high-level categories by

adding an additional category of ‘data requirements’, if this is deemed useful.

However, such requirements can normally be incorporated into the other four

categories.

DEFINE REQUIREMENTS