On March 5th, I presented the webinar, “Building a Better Backlog: Strategies for Long Term Success in Agile Development.” In the session, I shared strategies on how to build and maintain a good product backlog by describing the overall concepts and techniques for backlog management and how each of the project contributors can contribute to its overall effectiveness.
Specifically, I covered:
- What a product backlog is and how to create product backlog items
- How to write good user stories
- How to estimate product backlog items
- How to groom the product backlog, and
- The importance of treating the product backlog as a living artifact
During the webinar, we encouraged our attendees to interact with us by asking questions for the live Q&A session that we had at the end of the presentation. As a result, we received many great questions that we just couldn’t get to during the live event so we have provided answers to the audience’s questions below.
If you missed the session live, you can watch the recording and download my slides.
Don’t forget to register for our upcoming webinars! CollabNet offers multiple webinars a month that cover a variety of topics related to software development.
As promised, here’s the follow up to some of the live audience questions we received:
Q: What was that 2nd user story you mentioned? It was a good example – As a user I want to login to a website so that I can save my preferences…
A: We were pointing out how important it is to listen for not only what is said in a user story but also what is inferred. Compare these two examples:
- “As a user, I want to log in to the website so I can use it.”
- “As a user, I want to log in to the website so I can save my preferences and don’t have to reenter them each time I visit.”
In the first story, the implication is if I don’t log in I cannot use the website at all. The second story, however, implies that I can use the website without logging in but if I want it to remember me (and my preferences) I need to log in. Agile teams need to get good at identifying not just what is stated in a user story but also what is inferred.
Q: Is everything in the Product Backlog in some “User Story” format?
A: While it is certainly not required to use the user story format to create product backlog item, it is a very popular and useful way to describe requirements. However you choose to write your product backlog items, do try to keep them succinct for readability. You can link backlog items to more detailed documentation when necessary.
Q: Does the level of detail contain something about the how?
A: As we said, user stories are about the “what”. Tasks, created by the team, are about the “how”. Acceptance criteria is right in the middle, with some characteristics of both. Likewise, supporting documentation, such as design documents, may have strong elements of “how”.
Q: Are there instances where a backlog item is labeled as “L” or “XL” without it being an epic?
A: I consider “L” and “XL” to be valid story sizes. Anything bigger than that, however, would be an “epic” and the team would need to have that story broken down into more granular pieces before they could even consider including them in a sprint.
Q: What do you do when you have a Dev Manager that wants to use real numbers (in days) for User stories rather than story points? Mostly because he has 20 years in the business and feels he knows the workload well.
A: How does the team feel about it? If a team is keen to try relative estimation (which they often are) as ScrumMaster I would work with the manager to help him understand that what really matters is getting the team to the point where they make sprint commitments they can successfully fulfill. This is what will win over the Product Owner and, for that matter, the rest of the business. I feel you are describing an individual who has not yet internalized agile values. As long as the team is told how long work “should” take, they won’t truly self-manage.
Q: If the Product Owner role is a full time job, and you have a Product Owner that is not available full time – how do we make Scrum work? The Dev mgr has been grooming the backlog and the developers have been writing user stories in the Product Owners absence. This has been challenging for the team to understand the Product vision and to have “non-technical” user stories. Any advice?
A: A couple suggestions. First, stop doing this person’s job for him. As long as you give the Product Owner “excessive” help, he will never do the job. If you have not done so, start scheduling regular Story Time meetings to show him how to develop his backlog. Many Product Owners fail because they have received no training and don’t really understand what is expected of them. Next, work with the organization to make sure the Product Owner is held accountable for actually doing the job. If he sees it as something to be squeezed in during his spare time, he will never give it the thought and effort it requires to be successful.
Q: How do you manage dependencies between stories?
A: Discuss them. As a Product Owner, as soon as I did a preliminary ordering of my backlog the very next thing I wanted was feedback from my team. Often, they has ideas for moving user stories around to reduce dependencies or gain some efficiencies. I had final say on the order of the backlog but their input was priceless to me.
Q: Can we Use Case in place of User Story? What is the difference?
A: Use cases, at least most of the use cases I have worked with, a sometimes large, multi-page documents. A user story is a succinct single sentence. Use cases can support user stories but they are not the same thing.
Q: How do you prioritize based on “business need” driven by PO vs Dev need to develop high risk feature first. Looking at risk/value grid!
A: The short answer is: through discussion. A good Product Owner never works in a vacuum. He wants input from all stakeholders and that includes the team. But because the Product Owner is the one ultimately held accountable for the product, he has final say on priority.
Q: Who facilitates the Story Time session? And who be involved?
A: The ScrumMaster facilitates the discussion, since SMs are often master facilitators! However, the Product Owner should set the agenda. The goal of the meeting is to improve the product backlog. He should be intimately familiar with where it needs improving. Stakeholders may attend this meeting at the PO’s discretion. This meeting is a great tool for gathering requirements. And, of course, Story Time meetings, like all agile meetings, should be time-boxed. Regular meetings of 60-90 minutes are much more effective than one marathon session.
Q: Are there any guidelines around estimating the size of user stories, should the sprint length be taken into account?
A: Teams will come to consensus remarkably quickly on what, for example, constitutes a “medium” story. Leave this up to the team. But all stories must fit within a sprint. If they do not, they are “epics” and must be broken down.
Q: How do we organize support-related work (assuming it’s performed by same team)?
A: Some teams reserve capacity in their backlog for support work, based on historical data. But a necessary discussion to have when these “emergencies” pop up is “Can this wait until the next sprint?” True, sometimes the answer is no. But if you are doing, for example, 2-week sprints sometimes the “wait” would only be a few days. Then the work can written in a user story and added to the backlog.
Q: What is the most effective way a ScrumMaster could do in order to help product owner to maintain and clean up product backlog?
A: Show them what to do but don’t do their job for them. Writing the Product Backlog for your Product Owner only teaches him that, if he ignores his job, you will do it for him!
Q: As presented earlier the acceptance criteria should be negotiable. Does it mean that during demo meeting PO can change one of the acceptance criteria?
A: The “negotiating” of acceptance criteria happens in sprint planning, before any commitment has been made.
Q: Who or what types of people should attend the Story Time Meetings?
A: The ScrumMaster, Product Owner, Scrum team and any stakeholders invited by the Product Owner. On larger projects, the PO may find it useful to have a business analyst there to help document user stories.
Q: If you use t-shirt sizes to estimate, how do you derive sprint velocity?
A: Teams that use t-shirt sizing often use a numeric “weight” for each size to calculate velocity. The “powers of 2” scale is quite popular:
XS-1
S-2
M-4
L-8
XL-16
In this scenario, a team that committed to 1 large, 3 medium and 3 small user stories would have a sprint commitment of 26 story points.
Q: Can you please elaborate on what should happen during the planning meeting?
A: During the sprint planning meeting, the Product Owner wants the team to tell him how many user stories they are willing to commit to deliver in the upcoming sprint. To do this, the team and Product Owner must establish acceptance criteria for each story, or what it will take to call the story “done”. The team will also probably want to do estimation and also to begin task creation. They may even start to plan the work of the sprint and who will do what.
Q: What are the criteria / conditions for a “groomed” story ready for Sprint Planning meeting?
A: A “groomed” user story is one that is clearly written and of reasonable size, meaning it can fit into a single sprint.
Q: What are the competences required to be a good product owner?
A: Thick skin! Organizations almost always have more wants than they do money or time. Product Owners have to make tough trade-offs to get the most value possible given those limitations. Good Product Owners can make decisions, but never do so in a vacuum. They know how to prioritize and maximize value. And they take the job seriously.
Q: Regarding breaking down epics, is that process typically a PO effort or a team effort?
A: the Product Owner will almost always require help in breaking down epics. If he could do it by himself he probably would have already.
Q: Do you think that all items of the backlog should be estimated or is not necessary for the items at the bottom?
A: It is nice, after teams get some experience with agile, to estimate out a few sprints. This helps the Product Owner with planning. Much more than that is probably so inaccurate as to be useless.
Q: Are there any additional pointers for a product with a backlog that is thousands of items big?
A: Close your eyes and delete! Seriously, you need to winnow it down. Assign a Low/ Medium/ High ranking to each item. If it makes you nervous to actually delete items, move the “lows” to an “on hold” backlog. I personally have never seen an actionable and well-organized product backlog with more than a couple hundred items at any given time.
Q: If product backlog ordering is done in backlog meetings then is this overlapping with the Sprint
Q: Good afternoon Angela, when are you brining PO training to NYC? 
A: We currently do not have PO training in NYC, but I will pass along the request for it. 
Q: Assuming you have several released stories, what if the product owner decides that these stories must be changed?
A: Then he can write new user stories for these changes—no problem whatsoever.
Q: We have some great Product owners and then we have some that won’t participate that we are having to be stand-ins for, is there one key thing we can do to make this more successful?
A: Make sure you have the right people in the job and that they have the tools to do that job. Look at those “great” Product Owners and try to figure out why they are great. What do they do or have that the others lack? As an Agile coach, one of the top issues I am called in to help with is Product Owner problems. When I arrive I often find POs that have not been trained, don’ t know what is expected of them and are not getting help and support.
Q: If you work at an organization where the executives want the final say on the order of backlog items, how would you handle that?
A: The Product Owner has final say on backlog order so, if an exec wants that privilege, she has to take on the rest of the PO role as well. That usually doesn’t work out and eventually these individuals see they must delegate some authority. Delegation should not be a foreign concept to the average executive. Giving someone authority as Product Owner is just a form of delegation.
Q: Any hints about how to recognize if our backlog is “not in a good shape”? (Without reviewing each PBI one-by-one if possible)
A: A mature backlog has smaller, more detailed user stories at the top, less detail at the bottom. It is “chunked” into bodies of work like releases. It is full enough to keep a high-performing agile team busy. If this is your backlog, you are on the right track!
Q: What role does a business analyst play on the product backlog?
A: Business analysts often help Product Owners understand and write backlog items. They may also write supporting documentation and even help with testing.
The post Building a Better Backlog Q&A appeared first on blogs.collab.net.