T h i s d o c u m e n t i s p r o v i d e d f r e e f o r u s e p r o v i d e d t h a t t h e f o r m a t t i n g i s n o t c h a n g e d a n d c o p y r i g h t n o t i c e s a r e m a i n t a i n e d . R e a d e r s a r e w e l c o m e t o m a k e a n d d i s t r i b u t e m u l t i p l e c o p i e s o f t h i s d o c u m e n t .

v i s i o n a t e . c o . n z

The Agile BA

A Visionate process asset

Version: 1.0 Version date: March 2015

www.visionate.co.nz P a g e | 2

Document Information

VERSI ON REVI SI ON DATE DESCR IPTI ON EDITOR

1.0 Mar 2015 Init ial Creat ion Visionate

Contents

Document Information ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

The Agile Chal lenge ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Flexing to the Agi le Environment ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Scrum Master .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Product Owner ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Agile Requirements Analysis .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Value Realisation ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Solution Specif ication ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Technical Activit ies .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Configurable Systems.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Testing ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Conclusion ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 3

The Agile Challenge

As Business Analysts , we tend to be passionate and proud of what we do. We have invested the time and effort to develop ourselves and fine -tune our analytical skillset to the best of our ability. And it has taken a significant amount of time for the IT industry as a whole to truly appreciate the role and value that the BA brings to project delivery. We are now in a time when many organisations realise that BAs are indispensable, and this brings us great career satisfaction.

With the rising popularity of Agile-Scrum, we have seen an apparent shift of focus around the execution of project related analysis. We may feel that our hard won reputations are threatened by this new paradigm . The Agile approach encourages a reduction in detailed analysis and a scaling back of traditional documentation. There is a push towards generalist rather than specialist roles, and some might even go so far as to suggest that the analyst has become redundant in Agile environments . Given the situation, it’s no wonder that some BAs feel bewildered and anxious about the future of business analysis .

But as the Agile methodology has bedded itself in and we have observed how it truly functions in practice, we can see that there is no need for BAs to feel this degree of anxiety about their careers. Agile-Scrum does not remove the demand for the specialised analytical skills that we bring to the table. The BA skillset is still of great value within the Agile context. But it does mean that BAs will need to be flexible in how they perceive their role within the project team. The key to engaging with an Agile-Scrum project is to understand the approach more clearly, and to recognise how we as BAs can flex our hard-won expertise to contribute and provide value.

In the following pages we will examine some ways that the Business Analyst role can engage in an Agile-Scrum approach.

Note: in this document we will simply outline how the BA role applies to Scrum . The document is not intended to be an exposition of the Agile-Scrum method. As such, a familiarity with Scrum is assumed.

www.visionate.co.nz P a g e | 4

Traditional SDLC Model

The straata® version of the V Model represents the IT project lifecycle.

In an Agile project, these activities are stil l addressed, but the timing,

depth of detail and rigour may differ from the traditional approach. We

will use this model to structure our discussion and consider the role of

the Business Analyst in these activities within the Agile context.

Flexing to the Agile Environment

The aim of Agile, where appropriate, is to allow project teams to bypass

the formal approach used in Waterfall, thereby getting more work done

in less time. The effectiveness of the Agile approach depends on the

size and nature of the project, as well as organisational culture and

tolerance for risk. There are many different types of Agile

methodologies, with Scrum being the mos t popular.

© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 5

Agile methodology does not mean ‘no method’, and in this context the

value that the BA brings to Agile-Scrum in terms of applying a structured

analytical approach should not be underestimated.

There is great value in ensuring that amidst the swift and collaborative

environment on an Agile project, that a degree of rigour is maintained

to ensure that the project addresses the underlying business need and

provides genuine value to the organisation . This does not mean weighty

overhead and paralysis by analysis ; it means right-sized and effective

approaches to assure quality and ensure that the business value is

realised.

We will now look at the different roles and activities that the BA can

assist with.

Scrum Master

In Agile-Scrum terms, project management is

a shared responsibility of the self -organising

Scrum team. In practice, however, this

concept can become more aspirational than

real, at least until such a time as Agile -Scrum

has been well established within the

organisation and the Scrum teams have

accepted and taken ownership of managing

their own projects. In this context, taking

responsibil ity for the quality outputs of other people is a challenging

concept for many in IT, irrespective of their area of specialisation.

The Agile-Scum role of Scrum Master is not meant to be a project

management role. The Scrum Master is meant to be a mentor and guide

for the team to assist them in taking joint ownership. In practice

though, because of a reluctance to take shared ownership, or an

unfamiliarity with doing so, the Scrum Master will often wind up acting

as a de-facto Project Manager.

www.visionate.co.nz P a g e | 6

Irrespective of how the Scrum Master role is applied, as Business

Analysts we are ideal candidates for the role. We are already

accustomed to working with all roles in the SDLC to ensure that the

business benefit we help the business define at the earliest stage of

requirements, is designed, implemented, tested and deployed to ensure

value for our business stakeholders. Often in smaller scale waterfall

style projects, we may have acted as the Project Manager and as such

are accustomed to applying project management techniques.

So taking on the role of the Scrum Master is a natural area that we as

BAs can flex to in support of the Agile-Scrum method.

Product Owner

The Scrum team includes the formal role of Product

Owner. This individual is essentially the

representative for the business and is empowered to

make immediate decisions within the context of the

project. The Product Owner ensures that a focus on

the business benefit is maintained at all times and

that the viewpoints of all relevant stakeholders are

considered. Ultimately the Product Owner is

responsible for ensuring the project’s success.

In the ideal Agile environment, a dedicated Product Owner fro m the

business is available on a full -time basis to the project. However for

some organisations, this is simply not practical. The primary focus for

business people is running the business, so dedicating themselves to

fulltime project delivery is not feasible. In this scenario, the individual

best suited to step in as Product Owner is the Business Analyst. The BA

has the necessary skills and experience when it comes to understanding

the needs and drivers for the business. In this situation we can end up

with one of two scenarios. The first being where a business Product

Owner is available to the project part -time and attends only key

meetings and planning sessions. Outside of these sessions, the Business

Analyst supports the Product Owner by liaising with them and acting on

© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 7

their behalf. The second scenario occurs where there simply is no

Product Owner available from the business and so the Business Analyst

steps into this role full -time. In this way, the skillset of the Business

Analyst is indispensable in terms of supporting the objectives of the

Scrum team.

In the context of either supporting or being the fulltime Product Owner,

the Business Analyst will provide valuable structure in terms of

stakeholder engagement. A key thing to remember with Agile projects

is that just because the Product Owner represents the business and has

decision making power, this doesn’t mean they always know what every

area of the business needs. The danger here is that we may end up

following the restricted viewpoint o f a single business representative.

The key activity is that of stakeholder engagement, a core BA focus area,

and a critical expertise that we are able to provide to the project.

Agile Requirements Analysis

In terms of analysis, the Scrum approach does

not aim to define requirements with utmost

rigour and depth at the beginning of the

project. The reason for this is to support

speed and agility in delivering a project. This

approach allows for maximum flexibility in an

environment where the requirements are

changeable and the organisation does not

wish to spend a great deal of time attempting

to pin down the detail upfront. Requirements are understood at the

highest level at the start of a project, with the detailed requirements

being articulated just before the iteration or sprint where the

development is to take place.

In an Agile project, the preference is often to articulate requirements

as user stories. The user story captures the essence of the business

need and is not examined and elaborated u pon until just prior to

development – this is termed just-in-time analysis . These user stories

www.visionate.co.nz P a g e | 8

are prioritised by the Product Owner and held in the product backlog

which acts as a requirements repository. Like the Product Owner, the

product backlog is also a formal Agile-Scrum construct.

During the inception phase of the Scrum project, headline requirements

are identified and captured as epics. An epic is a large user story which

is typically too big to implement in a single iteration. Epics are then

decomposed into smaller user stories during the course of the project.

Scrum is primarily a software development methodology and the Scrum

team operates in iterations during which collaborative development

takes place. It is therefore important to note that much of the

traditional requirements analysis takes place outside of the iteration,

and as such outside the Scrum team. The Business Analyst works with

the Product Owner to create and refine the product backlog. The

Analyst typically works one to two iterations ahead of the team to make

sure the epics are decomposed into user stories and the necessary detail

is ready for the team to pick up and run with. As such, there is still very

much a place within the Agile project for a Business Analyst to apply

skill and rigour to process of identifying, validating , decomposing and

prioritising the requirements.

Over time, there has been a shift in attitude within Agile projects

towards documentation. In the early days, committing anything to

paper beyond user stories and acceptance criteria was frowned upon.

This made the Business Analyst’s role challenging as most traditional

BAs are experts in producing structured documentation. So to be

plunged into a world where documents were not permitted was

somewhat disconcerting. But these days, there is an appreciation within

Agile for the value of lightweight documentation. This is surely a

heartening shift for most BAs, and revalidates one of our hard earned

and well-practiced skillsets.

© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 9

In their zeal to embrace the Agile philosophy, advocates of the approach

can become unnecessarily resistant to anything that smells l ike a

traditional waterfall method. To a degree, this is understandable

because they need to maintain some rigour in adhering to Agile

principles. However, there is a risk in Agile projects that the importance

of structured requirements analysis is overlooked and undervalued. In

this situation, the Scrum team runs the risk of using agility as an excuse

to become sloppy in their efforts.

Value Realisation

In the straata® method we speak of value

realisation . By this we mean putting in

place measures to ensure the organisation

receives tangible value from the project

work we are doing. These are the

requirements to ensure that the delivered

product is actually adopted by the business, training is identified and in

place, resistance to adoption has been identified, mitigations have been

defined and ways and means to measure actual business value

realisation are identified. Whether a project is implemented using a

traditional Waterfall delivery methods or a collaborative Agile

approach, this concept is still relevant. We all undoubtedly want to

make sure the value of what we are doing is realised by the organisation

as a whole. Once again, this is an area where the Business Analyst can

assist. Whether Waterfall or Agile, specific requirements for value

realisation must be considered and included in the project scope, and

as the BA it is our role in Scrum to ensure they are captured in the

product backlog.

The straata® method provides an approach that can be f lexed for use in an Agi le environment in order to rightsize the analysis effort, thereby ensuring a degree of rigour is maintained without overcooking it. Click here to access documents that cover the straata® approach for requirements analysis.

www.visionate.co.nz P a g e | 1 0

In terms of assessing whether or not the project has realised the

intended value, this is something that will generally occur outside of the

sprint, potentially using tools delivered during the sprint. For example,

a report identified as a requirement for Value Realisation measurement

and generated during the sprint could show that the functionality added

to the ABC website has increased customer sign-ups by 20%.

Solution Specification

During the solution specification activity

the Business Analyst lays out the

functional and non-functional

specification for the solution. The degree

to which this analysis activity is necessary

during an Agile-Scrum project will depend

upon complexity and level of business

engagement in the project. In some

situations, functional specification will

occur on-the-fly as part of the sprint. And

in other situations, the developers have sufficient analytical abilities

themselves to design the solution. In both cases, the role of the BA may

be reduced in this activity. However, in some projects there may be a

need for additional rigour and focus in this area. Developers may feel

the need for a more detailed specification of the functio nal design for a

requirement, or testers may need it in order to comprehensively design

a testing regime. Functional specification of requirements, or detailed

exposition of acceptance criteria for testing is of course a core skill set

of the BA function.

© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 1 1

Technical Activities

The technical arena is one in which the Business

Analyst does not often venture, with the exception

being those Business Analysts that have come from a

technical background. Activities in this area involve

ensuring the right technical principles, protocols and

procedures are in place, application architecture is

defined, and technical architecture patterns and

standards are identified. How this gets done will

depend on how Agile-Scrum is being used by the

organisation and the shape of the internal IT function.

Some organisations will mix these activities into the sprint, on-the-fly,

whilst other organisations will take a more formal approach . The formal

approach may involve a separate Scrum team tasked with creation of

the application and technical architecture. Another formal approach is

to include specific architectural requirements as pre-requisites in the

product backlog, or even via separate preliminary sprints to set-up the

required technical environment. BAs with a strong technical bent may

dabble in this area, but traditionally most BAs shy away from this and

leave it to the technical experts. And it’s safe to say that most BAs will

steer will clear of actual hands on development and coding. This

generally is not a role that the BA can easily flex to fi ll. The exception

once again, being those BAs that have come from a strong technical

background.

www.visionate.co.nz P a g e | 1 2

Configurable Systems

In the situation where a configurable off-

the-shelf package is being implemented, a

different dynamic applies. Typically,

configuration of an off-the-shelf system

involves the identification of business

rules (i.e. detailed requirements) which

are then applied to the package through

in-built configuration.

The package solution may require specialist configuration resources to

be involved (e.g. SAP FICO specialists), or it may be amenable to

configuration by an individual knowledgeable in the business process.

In either case, as BAs we are well suited to be involved in determining

how the business requirements can be fitted to the capabilities of the

configurable package. And in some cases, we could even be involved in

carrying out the configuration itself.

Testing

The validation activities that are

traditionally handled by a formal testing

function are, with Agile-Scrum, the

responsibil ity of the Scrum team. These

activities are carried out within the sprint.

The Scrum team may or may not have

formally assigned testers.

There are a number of different aspects of testing to consider , and

Business Analysts are able to assist in many of these areas. Technical

testing such as integration and unit testing are not something that most

BAs would attempt, however a BA with a technical background may feel

comfortable lending a hand in this area. Functional testing of the

solution is an area that most BAs could flex to perform, depending of

course on the nature of the project and complexity of the system.

© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 1 3

User Acceptance Testing (UAT) is an activity that traditionally the

Business Analyst will assist in coordinating. Depending on the level of

business engagement with the project, the BA may simply assist with

scripting and coordinating the testing, right through to actually

participating in the execution of UAT. If the business is heavily engaged

in the project, then the UAT may occur during the sprint, otherwise

some form of UAT will need to be conducted outside of the sprint.

Conclusion

In summary there are a number of roles within the Scrum team that are

ideally fil led by Business Analysts. There are also roles which we can

flex to, in support of the multi -skilled approach promoted by Agile

thinking. Irrespective of the project methodology in use, we should all

have the same ultimate goal: to deliver a quality result to the business

that provides measurable value. As Business Analysts, this is our core

focus.

To enable our own flexibil ity and be capable of filling the different roles

described in this document, we as BAs must cultivate a mind-set of

willingness and cooperation. In doing so, we must shed any attitude

and rigidity around what a “Business Analyst” does and does not do. At

the end of the day, on an Agile project, the BA needs to be the sponge

that expands and fill any perceived gaps within the team. Much of the

success of the Agile approach lies in the empowerment of a self -

organising team. The BA, and all members of the Scrum team for that

matter, need to adopt an attitude of serving the team in any way

possible to support the successful execution of any given sprint.

www.visionate.co.nz P a g e | 1 4

The nature and degree of our involvement as BAs will vary, depending

upon the particular organisation. But it is clear that regardless of how

Agile-Scrum has been adopted in practice, there remains a primary

requirement for Business Analysis expertise within the Scrum team.

Thank you for reading our document on the Agile BA. For more

information on the straata® method, please visit our website

www.visionate.co.nz