Guess what.

It is entirely possible that you will run into challenges on your path to becoming a successful, confident Agile Business Analyst. Everyone has challenges, and they vary somewhat from analyst to analyst and by team and organization.

One of the bigger challenges I've heard is phrased in a few different ways:

"I don't have enough time to analyze things."

"I'm always in catch-up mode."

"I feel like a bottleneck, like the team is waiting on me."

I don't want you to be a sad, stressed-out Business Analyst, so here is a solution.

During the sprint, gradually shift your focus from the sprint backlog to the product backlog.

During the Sprint Planning session, you’re totally focused on translating the most important PBIs from the product backlog to the sprint backlog. And then the sprint begins, and you’re 100% focused on the sprint backlog and the stories it contains.

Don’t stay this way. If you do, you won’t be fully prepared for the end of the sprint and the beginning of the next one. Instead, progressively shift your mindset from the sprint backlog to the product backlog during each sprint.

The mindshare your product backlog gets should be equal to the percentage completeness of the sprint divided by two. In other words, by the end of the first half of the sprint, you should be thinking about the product backlog a quarter of the time.

If you don't like equations, here are a couple handy tables.

If you use 1-week sprints:

If you use 2-week sprints:

If you use 4-week sprints: Your table will be too long, and it will be annoying for the other readers to scroll past it. Don't be selfish. You'll have to figure it out yourself.

If you use 3-week sprints: You're strange. Possibly a mutant. Touch base with me, because I would like to study you.

Illustration

Let’s assume we run two-week sprints, as in the table above. On day 1, the sprint will end as 5% complete. Accordingly, you should be almost entirely focused on the sprint itself. Make sure everyone understands what they are doing, what the stories represent, and that the acceptance criteria are understood.

On day 2, team members may point out issues with the stories that might have ramifications for future sprints. You should note these down, but not spend too much time on them. After all, the sprint will only be 10% complete, and you’re only giving 10% of your mindshare to the product backlog.

On day 6, you’re spending a couple hours sitting with the Product Owner to help her re-prioritize the product backlog, adjust it with what you’ve learned over the past week and so on. This activity will continue throughout the week.

On day 10, the last day of the sprint, you’re spending about half of your time on the next sprint. You already have a good idea of what its scope will be. During the Sprint Review, when managers ask why a particular feature hasn’t been done yet, or what the plan is for future functionality, you’ll be prepared to answer because you’ve spent a good amount of time focusing on the product backlog.

And the next Sprint Planning session will be smooth and quick, giving more time to the team to deliver valuable functionality.

Let me know how this is going for you. Comment below!

Subscribe