You wrote in the tree killer magazine Softhouse Lean magazine about the need for a product owner to know financial analysis skills and that you had tought it in a few hours. I’d like to read the lecture in a blog.

/OF

The general answer is that you want each Product Backlog Item (PBI) to be something of value to users, customers, etc. Yes, we can stretch an argument and saying that discovering how to do something is valuable to users but that’s not really what we want. We want items that deliver that value to users or customers. Before the term “product backlog” caught on, back in the mid-90s I called this the PB a “Prioritized Feature List” and I sometimes wish we still called it that. That would get rid of any questions about whether “Backlog Grooming Meeting” is a PBI (nope) and the same for discovery tasks. If they aren’t features, they aren’t on the Prioritized Feature List.

The real question becomes whether they go on the sprint backlog. I would put things like “discover how to do…” on the sprint backlog. I wouldn’t put “hold grooming meeting” on the sprint backlog. That’s something we do every sprint (presumably) so I don’t want to incur even the minimal overhead to track that as a task. Discovering how to do abc this sprint is different than what we’ll discover next sprint so that’s worth the tracking effort.

However, this last part is entirely my opinion (and recommendation). But it’s not a strong recommendation of that approach. When I see 2-3 approaches work with equal success, I’m indifferent to which other teams should use. That’s the case here–plenty of teams are successful tracking such tasks, plenty of teams are successful not doing so. So, the biggest key is doing what seems most helpful to you but doing it consistently from sprint to sprint.

Example 2:
PBI Link to Assets (Discovery)
• Task – DEV/BA: Meeting with POs from other teams on integration points
• Task – BA: Research/Updates to PBI
• Task – etc.

PBI LNII Checklist Integration (Discovery)
• Task – DEV/BA: Meetings
• Task – BA: Research/Updates to PBI
• Task – etc.

Example 1:
PBI for April Research/Discover
• Task – LNII Checklist Integration 6 hours (meeting time for Dev and BA + updates/follow-up to LNPS PBI 18675 from meeting)
• Task – Link to Assets 10 hours (meeting time for Dev and BA + perp/updates/follow-up to Link to Learning PBI from meeting)

We do have weekly grooming sessions for the team, but more work discovery work is often needed than the time we have set aside or grooming sessions. We don’t include planning meetings or grooming sessions as PBIs, so should we include these items as PBIs? We also have a time tracking system so it may be that these are not tracked as PBIs, but the time spent should simply be logged in the time tracking system. I am not sure if there is a right or wrong way to handle this, but was wondering if you have any recommendations based on your experience with Scrum?

As for that report, it’s never been anything I’d be interested in. There is little to no evidence that feeding back actuals to individuals improves their future estimates. I suspect that feedback back to them the percentage of times they were wrong will do nothing more than depress them.

Let’s say that at the end of each Sprint, the team identified the stories it did not size accurately and kept track of them (but does not change them for the burn-down charts). Would a historical report of what % of stories were not sized accurately be useful? Would this provide a picture into the maturity of an Agile team? Have you seen teams do this? What are your thoughts on this?

We never plan a sprint without having at least one user story that is planned to be completed.

Hi Mike,

Is there anything stopping a company to try to have their portfolio/program product backlogs DEEP and have their Epics INVEST?

Is your idea to use the word “appropriately” to allow such kind of scaling?

So, for instance, using T-shirt sizing with epics (using 2 for small, 5 for M, 13 for L, 21 for XL and 55 for XXL), I could get epics sized appropriately then.

Also I would want to have a portfolio backlog that is prioritised and estimated (so we could drop features that are too expensive), epics to be independant, negotiable etc?

What is your view?

Regards,
Ch

PS: when writing epics, I always try to use the INVEST Model and it does work well.

I was going to point you toward the Agile Testing book as that is a great resource. Additionally you may want to look at this blog post on removing finish to start dependencies (a frequent problem related to testing) and perhaps this one on the test automation pyramid.