Using Business Analysts with Scrum

There has been increasing attention paid to the role of Business Analysts in the Scrum development methodology. Feedback from some early adopters of agile methodologies seemed to suggest that the role of BAs had been made redundant via the use of short feedback cycles. Certainly I can find no mention of BAs in some of the seminal agile books like "Extreme Programming" and "Agile Project Management with Scrum".

The death of Business Analysts has been greatly exaggerated. A quick google will show you that BAs with agile experience are in great demand.

Let me tell you how we use BAs with Scrum. Usually the Scrum Master meets with the Product Owner before the sprint planning meeting to "groom" the product backlog. We push that meeting back to a week or more prior to the planning meeting (we are on month long sprints) and send the BA to meet the PO.

In addition to grooming the backlog, the BA digs into each of the user stories in more detail. He then goes away and prepares a specification based on the priorities identified. This spec is usually complete by the time the sprint planning meeting occurs, and is used for estimating and after that as a development spec. Toward the end of the sprint, the BA then tests the system against the requirements.

You've probably got some questions -

• How big are these sprint specs? We have four developers in one of my teams, our sprints are a month long, and the sprint spec is usually about 20 pages long.
• What's in the specs? We make use of Gherkin, and also screen prototypes done in Balsamiq. We also do acceptance criteria for each user story.
• What do programmers think of the specs? They LOVE having specs. Rather than having to ring up the PO all the time, they can just get on with the coding. When a BA is on holidays and there are no specs available, they are not happy.
• Have the specs improved the quality of what you are building? I think having specs, acceptance criteria and tests against those criteria have certainly reduced the number of bugs in the code, and stopped us going down dead ends.

Ok, you say, so it's been effective. But you might have some other objections -

• Doesn't writing specs violate a cardinal agile principle? The Agile Manifesto says that we should value working code over documentation. I agree! However, it doesn't say we should have *no* documentation, just that we shouldn't create these huge specs and spend all our time trying to keep them up to date. We don't do that. We create a spec per sprint, and it's really a disposable document, forgotten once the code has been written.
• Aren't you just describing the role of the Scrum Master? The Scrum Master certainly does requirements analysis in classic Scrum. However, I don't believe it is usually to the detail and quality that a professional BA will give you. I've also found that Scrum Masters are usually far too busy to spend time doing the requirements in detail.
• Don't you lose agility? I don't see why you would. The specs simply reflect the priorities the PO has set - they don't change them. And the specs are a guide, not a shackle - if something doesn't work out when it comes time to code, there is no problem with trying something different.

I hope I've shown you how useful Business Analysts can be on a Scrum project. I couldn't live without them now.