Many people wonder, what does the BA do in an Agile team?
We’re all used to stacks of documentation before we can start on something, but this is where we need to change our mindset about what we’re doing. As traditional guardians of the requirements, the BA's role changes more than most. We are aiming for Just-in-Time requirements.
JIT = Just In Time. The philosophy of JIT is simple: the storage of unused inventory is a waste of resources. We don’t want to build up a stack of stuff because we’re only going to have to revisit it when we come to work on it or when the business changes their mind (unheard of!). In our knowledge-based work, we don’t see the build-up of inventory because it’s all in a computer. So what does this mean for us? Not spending time on something, documentation or development, before we take it into a sprint – leaving the work until the last responsible moment.
Think about the granularity of the information we use, at each stage we only do just enough to get to the next stage:
- In the backlog – big boulders farther off, small rocks at the top of the backlog. Not a lot of time spent here
- In refinement – small rocks get to pebbles ready for the sprint. Identify and clear any business decisions, dependencies, design fundamentals to be decided. Back of a fag packet, whiteboard diagrams, notes on the story, Specification By Example
- In planning – pebbles become grit – common understanding among the team so that we can recognise a task is needed but not the detail of the task. More notes on the story, whiteboard diagrams
- In sprint – grit becomes fine sand - when we start the story a team discussion gets the fine grain detail sorted. Write up exactly how the thing was done so the next guy knows – As-is, To-be
All so that, when we work on the story in the sprint, it flows through the team like sand through the hour glass – with as little friction as possible. It’s the team’s job to ensure the BA is not doing too much upfront and the BA's job to ensure the team has enough to understand what the customer needs at the end. Then the team can decide how that can best be delivered, including what documentation is needed.
So think about the documentation you’re doing – keep it simple, focused on the customer’s end need and only just sufficient to get us to the next step – JITumentation!
For all the BA's out there, here’s a good documentation on JIT requirements and you can find many more as this is a hot topic in the Agile world.
And for those who like a simpler read, here’s a blog on requirements as inventory.