If you are reading this, one of two things has happened to you: The IT Budget Gods have smiled on you and have given you funding for an additional resource to add to your Scrum Team. You are trying to figure out who to staff. Congratulations! Your Scrum Team is struggling, and you need some […]
If you are reading this, one of two things has happened to you:
In either case, I thought the best way to demonstrate the value of a Business Analyst on a Scrum Team is to talk about some of the problems that you may be experiencing.
So, without further delay:
1. You get to your product review and your product owner has major issues with what you’ve done.
2. You get to stakeholder review and they have major issues with what you’ve done. (Yikes!)
3. Your developers feel like they spend a lot of time doing stuff that isn’t fun to them (like figuring out the requirements.)
4. You have a well-intentioned product owner or stakeholder who wants to fill your product backlog with a binder of requirements from ten years ago and asks you to build it.
5. You have a lot of data elements floating out there and as a team and you struggle to maintain consistent information where data should be pulled from.
6. You are dealing with complicated processes or user workflows.
7. You are required to maintain documentation for the purposes of traceability, training, or posterity.
8. Your user stories are inconsistently sized and, therefore, hard to estimate.
9. Testing is an afterthought.
10. Your developers spend a lot of time doing unplanned work.
If one or more of these are true, you might need a Business Analyst.
Have you experienced other Agile/Scrum software delivery problems that a Business Analyst was able to help solve?
Agile experts think great product owners act as entrepreneurs for their product. Product owners and...
You are probably familiar with some form of the following: Should we be using story...