Product backlog items
Hi all,
I'm a very new scrum master just starting my project. I was wondering if Business Analysis tasks/issues should be added to the product backlog or are those the responsibility of the PO and only implementation-related items should only go into the product backlog? Also who is responsible of keeping track of any BA activities taking place in the project, Is there a backlog for those activities/issues?
Thank you very much in advance
Kostas
If the work doesn't represent something of value to be implemented, why would it be scoped on a Product Backlog for a Development Team to do?
How would the Product Owner order that work in relation to other items?
If the work being done by the BA is needed in order to produce a potentially releasable increment in each sprint, why wouldn't that individual be part of the Development Team? The DT should have all of the necessary skills needed in order to do the work. No where does it say that DT is made up entirely of people that have Developer in their job title.
Also who is responsible of keeping track of any BA activities taking place in the project, Is there a backlog for those activities/issues?
Does the Scrum Guide say anything about a Business Analysis Backlog?
I was wondering if Business Analysis tasks/issues should be added to the product backlog or are those the responsibility of the PO and only implementation-related items should only go into the product backlog?
According to the Scrum Guide all work needed for a product should reside in the Product Backlog. The Development Team will pull items from the Product Backlog to create their Sprint Backlogs. So I go back to my initial question for you. If the work being done by the BA is needed in order to produce a potentially releasable increment in each sprint, why wouldn't that individual be part of the Development Team?
HOWEVER: Your question phrasing leads me to believe that the work the BA is doing needs to be done before the Scrum Team begins to work on it. If the work that the BA is doing is to provide the Product Owner with the information needed to create and clarify the stories that are being put into the Product Backlog, then that individual would be working outside of the Scrum Team and that work would be tracked somewhere else entirely. How much of and where the information provided by the BA is captured for the Scrum Team is entirely up to your organization and Scrum Teams to decide.
I just want to add my experience to the previous comments.
I work as a BA on a Scrum Team and here's how we do it currently.
My work generally involves:
- Clarifying PBIs on the Product Backlog (often writing the PBIs, asking the Product Owner what they mean by certain things, generally getting it to a state that the developers can understand). The work to do this is not added to any backlog, it's just done as part of my role.
- Clarifying PBIs that are already in the Sprint (on the Sprint Backlog). This often involves me speaking to the Product Owner or other business representatives to get an answer for the development team. In this instance, I put a task on the PBI on the board, as it is needed to deliver the feature. A common example of this is to clarify the values to appear in a list of values.
I'm also aware that in many Scrum teams, a BA is not needed, and this work is done by the Product Owner :)
Hope this helps.
So do you suggest not documenting this work anywhere?
On my current team, my responsibilites are quite similar to Ben's. However, we do put my work on a backlog, but not the Sprint Backlog. This enables me to put the same transparency over my work as the developers put over theirs.
So do you suggest not documenting this work anywhere?
I would argue that the work is 'refinement'. Therefore it is not on the Sprint Backlog.
Refinement should take around 10% of the teams time, of which the BA does a big chunk since he/she is full-time working on it. Probably because you need a BA, the particular context requires more time spent on refinement.
The progress is seen in the Product Backlog, where you can check that the PBI's (especially the top ones) are continuously becoming more ready. So the Product Backlog is the documentation.