In a recent poll about the BA role in agile, 61% of 23 respondents indicated that the BA develops the product backlog. After having created my first product backlog, I’m actually surprised that this number is so low. As I’ve experienced it, the product backlog is really the core requirements deliverable for the project and ownership by the BA (or a product owner with BA responsibilities) is critical.
As with just about any well-managed project, we blended methodologies and best practices. I started with a traditional scope statement and features list and then used that features list to generate a preliminary list of user stories, or product backlog. The features list is fundamentally business-driven and when I started work on the project we had not yet defined how we’d manage requirements communication with the out-sourced development team. At the project kick-off with the development team, we reviewed a fairly final draft of the scope statement and started discussions around detailed requirements communication. The development team is part of an agile shop, so regardless of who did it, a product backlog and user stories would be created. The more I thought about it, the more it made sense for me as the business analyst to own these deliverables.
I encountered some interesting challenges creating the product backlog. First off, identifying a user story blends elements of requirements and design. As I worked through my list, driven by my understanding of what the business wanted, I kept running up against the question of “how will it make sense to build this in a delivery cycle?” To balance these two perspectives, I drafted the product backlog, then we tore it apart as a team into deliverable nuggets of functionality. For us, the question the product backlog answered was “given what we know about scope, “what is the best way to deliver in an agile environment?“. So, we were blending agile with more traditional methodologies a bit to the benefit of the business team (that cares about scope) and the technology team (that has optimized their development process to deliver in sprints).
The second challenge I encountered really centered around the syntax of a user story. Still waiting for Mike Cohn’s User Stories Applied book to be delivered, I read as much as I could on the web and did some hard thinking. In the past, I’ve been an “ability to” analyst…never again. After attending a webinar by IAG, I worked through a new format:
“[Somebody] does [something] with [some information]“.
This provides a much more powerful way to capture features and also ensures you are capturing all aspects of the feature. And the standard user story format?
“As a [user], I can [do something] so that [perceived benefit].”
These were surprisingly similar. I really played around with the benefits statement and found that sometimes it added real value to the story and other times real confusion. I consider it optional. But the standard user story format was missing the “some information” component that had really helped flesh out many of my requirements. Therefore, most of the product backlog ended up in the following blended format (items in parens are optional):
“As a [user] (with some information), I can [do something] (with some information) (for some perceived benefit).”
Perfect? Hardly. Good enough? Definitely.
I’d welcome any comments you have or tales about your first or a challenging product backlog. I have a lot to learn and I can only hope that by sharing my experiences, I will learn more from others and also inspire others to try new, fruitful ways of accomplishing their objectives.
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 2 comments… read them below or add one }
I think the primary challenge for the business analyst (BA) as product owner is that often the BA does not have control of the product backlog.
If the BA has complete control, they are set. If not, then they are probably not real product owner. Ask these questions:
- Do they develop the backlog?
- Do they prioritize the backlog?
- Jake Calabrese
http://www.vimstreet.com/blog
Yes, on this project I am not the product owner, but I own the product backlog in terms of defining backlog items and writing the stories. So, I develop the backlog and often facilitate it’s prioritization. All of this happens with buy-in from the business stakeholders.
Complete control of the backlog comes with a set of responsibilities that are a bit beyond, in my opinion, those of a “BA”. As a BA you should be working with a stakeholder for business priorities and with a PM or development team for implementation priorities.