The Agile Business Analyst

Mar 05, 2015 Chloe Powell

There’s enough literature on the SCRUM Based Agile Implementation Methodology, but what perhaps isn’t documented as well, is the important role of the Business Analysts – and their part in shaping the success of a customer implementation. The focus of this document is to summarize what a Business Analyst can do (or do better) in Agile Implementations using a SCRUM approach to ensure the maximum chances of project success.

Traditional Implementation Approach

To be able to appreciate the key success factors, it is important to have an understanding of some of the most common approaches for an enterprise application implementation.

Traditional ’Waterfall’ implementation methodology is a sequential cycle, although with many variants. A careful planning exercise with wholesome documentation, design and approvals later, the end product is tested and delivered.

The greatest advantage here is that it’s supremely logical – but therein lies its ultimate weakness; as humans aren’t always logical. Human ideas and planning are, by definition, expected to be constantly improved and innovated upon. The traditional approach debunks great ideas late in the waterfall, since they are a threat to the process.

In addition, the written word is expected as final, and it is expected that the 200+ page requirement document is read and understood.

Agile and SCRUM

Agile cherishes and celebrates human characteristics – learning, innovation, and change. Agile principles stress on building applications that people can get their hands on quickly, instead of spending a lot of time documenting them at the beginning. Agile implementations include cross-functional teams capable of making quick decisions, and who are encouraged to do so. It emphasizes immediate iteration-based work, with continual customer feedback.

The most common and popular of the Agile approaches is SCRUM – it’s an iterative incremental framework for projects, and is built on pillars called ‘Sprints.’ Sprints are successive and can be of 2 or 3 week durations, during which the ‘product backlog’ features are defined. A daily team stand-up meeting is held to review progress and iterate on the next steps to complete the remaining work. At the end of the sprint, a working and shippable product that is integrated and tested is demonstrated, delivered, or both, to the customer.

The recurring theme throughout is ‘self-organize & evolve-until-complete’ - for all stakeholders involved. Customer team(s) and implementation teams alike need to embrace the dynamic self-evolving nature of the implementation – something that can be challenging for traditional approach-based organizations to reckon with.

SCRUM Framework

Critical Success Factors

Research Studies have shown that the CSFs for an Agile Scrum Development include the 3 C’s (Communication, Collaboration and Customer Involvement) built on 6 dimension factors.

These have led to good results on the 4 parameters - Scope, Time, Cost, and Quality.

BA Best Practices for SCRUM Agile Implementations

A Business Analyst typically plays the role of a Product Owner in a SCRUM Agile Implementation. Together with the Scrum Master (11%), studies have shown that the Product Owner role (62%) contributes almost 75% to the project.

1. Influencing the SOW Definition to Support an Agile Delivery

Business Analysts can influence the delivery methodology even prior to the start of the implementation. Together with various stakeholders, the BA can emphasize the need to go ‘Agile’ - An SOW which helps define the below could setup the project for success nicely.

• Clear scope on modules and solution – For Ex: ‘Internal Audits Application with Asynchronous Integration with SAP, Legacy ABC System via csv files only’
• Detailed list of in scope items and scope Exclusions- using Agile Terminology and deliverables
• Phased implementation (For Ex: Phase 1 - Requirements Gathering & Phase 2 – Implementation)
• Billing milestones based on product demos or release to Customer Environment
• Type of Contract – T&M Billing with/without Cap or Fixed Price

2. Prep-Work Before the Project Kicks off

An Agile project, like any other project, needs prep work and research before the initiation.

• Getting executive champions and Stakeholders on-board the Agile Initiative
• Using existing Agile Implementation knowledge within the enterprise, without reinventing the wheel
• Including the ‘right’ people in the team at the right time – the emphasis on ‘right’ not the ‘best’
• Forecasting for IT infrastructure and tool needs
• Developing a customer-centric list of product backlog features and items

The work done prior to the kickoff of an Agile project has a much higher impact versus a traditional implementation approach – simply because the dynamic nature of the implementation does not provide much room for error.

3. ‘Just Enough’ Requirements Gathering

Requirements in an Agile Project, by definition, are expected to evolve – but not completely change. It’s a fine balance to gather requirements without ‘overdoing’ it.The requirements gathered in the Functional Specification document need to include:

• Assumptions,
• Data field Definitions,
• Process flows,
• Screen Descriptions,
• Business rules

The focus is on not adding extra work through the requirements process – In a professional services team context, this could mean sticking to the pre-packaged solution as much as possible, thereby reducing requirements ‘gathering’ altogether.

4. Effective Product Backlog Refinement/Grooming

The Product Backlog and the Functional specification work need to work hand-in-hand. The focus in the backlog grooming sessions needs to be on working with the customer to:

• Define and refine the features listing,
• Identify potential gaps that need to be revisited when we together have better clarity and
• Recognize items that depend on each other and potentially need to go together to make a shippable product/feature set

5. Helping Setup the Sprint Goals and Tasks During the Sprint Planning

Although by definition, Testers are the core participants in the ‘Sprint Planning’ meeting, and get together to define the ‘How’ for the ‘What’ from the Product Backlog, the BA can contribute as Product owner with inputs on:

• Defining functional sprint tasks
• Dependencies between backlog items
• Design approach to leverage pre-packaged features and functionality as much as possible
• Recognize change requests and take them through the CCB process

6. Constructive and Fruitful Daily Scrum/Stand-Up Meetings

The Scrum Master goes around the table asking the following 3 questions:

• What did you do yesterday?
• What will you do today?
• Are there any impediments in your way?

The BA can help the Scrum master avoid the common pitfalls such as micromanagement and off-track discussions.

7. Powerful and Impactful Pre-Demos and Demos to the Customer

Pre-Demos (to the core group) and Demos (to the business user group) during each sprint provide continuous and contiguous visibility to customer stakeholders – while maintaining momentum. For the implementation team, it’s a great platform to receive feedback and reactions to the feature set/product. A regular release of features for end-user review also means high team availability and short turnaround time – a BA needs to wear multiple hats, and be open to take up challenges over and beyond his/her area of responsibility.

8. Evaluating Sprint Feedback and Sprint Retrospective

The BA needs to take the Sprint Feedback and retrospective comments back into the Product Backlog, and needs to follow the same cycle of discussion, documentation and decisions (including if a CR/not).

9. Productive User Acceptance Testing

Apart from the bug triage and functional testing inputs, with Agile deployment it is critical for the BA to work with the customer and define a criteria for releases – For Ex:

• All P1 defects 1-2 weeks from triage date (next release),
• All P2 and P3 defects 3-4 weeks from triage date (release after next release),
• All P4 and P5 defects Post Go-live.

It’s important to realize that SCRUM is a framework that encourages transparency – and allows ‘inspect and adapt.’ It makes the weakness or flaws visible for all team members to work together on a resolution.

For Ex: A task delivery beyond the sprint time-box does not imply failure - rather it’s an experience to help the team estimate and plan better for subsequent sprints.

In summary, a Business Analyst needs to play the role of an ‘Agile Evangelist’ to encourage this within the team.