Some questions about Product Ownership

Hi Boris,

Below are my thoughts

1) "Can the Product Backlog contain testing items, e.g., such User Story:"

My thoughts/questions:

1-A) Scrum Guide says "The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value." 

1-A) Why didn't you consider this "New Kind of Testing" an enhancement to the team process? (e.g. Implementing Unit Test Framework to automate the test process)

1-B) If this "New Kind of Testing" is small enough and can be done relatively quickly, wouldn't it make sense to "Just do it" together with other PBI?  

1-C) If this "New Kind of Testing" requires research. Maybe a Spike is needed?

https://www.scrumalliance.org/why-scrum/agile-atlas/agile-atlas-comment…

2-A) Why do you think "ONLY some PBIS should be decomposed"?

2-B) If the team knows what they are doing.  And within the time-boxed meeting, they can clarify and create plans for lots top high priority PBIs with the time-boxed Sprint Planning Meeting, why not?

3-A) Scrum Guide states " As new work is required, the Development Team adds it to the Sprint Backlog"

3-B) Why are you concerned if the new task can be added to the Sprint Backlog?  

3-C) How is this new task helps the team to achieve the Sprint Goal?  

3-D) Otherwise, why is the team wants to work on the new task that doesn't have anything to do with the Sprint Goal?

4-A) If the Dev Team can discuss, clarify, decompose and provide estimation in Sprint Planning meeting for this "very hot PBI of very high importance", why not? 

What scenarios should the team not work on this "very hot and very high importance" PBI?    What about urgency, is it urgent and need to be addressed immediately? 

5-A) Scrum guide says "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."  , which including "ordering the items in the PB.."

5-B) If PO is temporarily absent (e.g. very ill) and the Development Team can help. Why not?   

What scenarios do you think this can cause a concern? 

e.g. Does the Development Team has the necessary knowledge, skill, and business understanding to prioritize items in the Product Backlog?  

 

Hi Tony.

Thank you so much for your detailed and quick reply.

1) About the first question - I totally agree with you. 

2) About the second question. If the team makes too many plans (detailed plan for all selected PBIs), isn't it waste from Lean perspective? Sprint backlog emerges during the Sprint. These tasks can be changed, removed. So, maybe, it is more correct to plan only for first several days of the Sprint (and for other days to have some less precise estimated items - not tasks)?

3) I mean this Team member thinks this task is of high importance for the team and adds it to the Sprint Backlog ("as new work is required") during the Daily Scrum. And commits to it. But the rest of the Team realize they can't agree with this. They need to have a discussion, which will take more than 15 minutes. So, it will be conducted after the Daily Scrum. But then it seems, that the Team member, who proposed the new task, didn't use his time during the Daily Scrum properly (in particular, to declare what he Actually intends to do). Because in reality his task will be different - negotiated with the rest of his Team. This could be a problem for transparency.

4) This new PBI is urgent,but the Team doesn't understand it very well, so, it should be reviewed and discussed. But if the Sprint Planning meeting time-box is not enough to succeed with it? What should they do? Should the Product Owner tell the Customer in this case: "We can't fulfill it right now" ? I think he should do this very thing as they can't deliver this feature immediately. Maybe, they should also undertake some research spike. Right?

5) If the Team doesn't have enough business understanding to make ordering. And the Product Owner is not available for 1 Sprint. Who could help the Team? Because they are blocked. For the Product Owner this situation is not usual, but extraordinary. I mean we have such kind of scenario.

Thank you once more!

#1 - what would be the best way to represent this work within the Product Backlog that would allow the Product Owner to understand it and prioritize it accordingly?

#2 - as a PO, what is your concern exactly about the amount of decomposing the team wants to do for PBI's that they are forecasting for the next sprint?   They should be allowed to analyze the item in whatever way works best for them in order to ascertain whether they can be confident in completing it in the sprint.   Agile Principle #5: "Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done."

#3 - as a PO, why do you care if the team determines that tasks or PBI's need to be added/removed from the Sprint Backlog?   They have forecast meeting the Sprint Goal agreed to during Sprint Planning - why are you concerned with how they may achieve it?   And why do you care how the team conducts their Daily Scrum?

From the Scrum Guide: "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours" and "The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team."

#4 - it is asking a lot of the Development Team to assess a new, unrefined PBI during Sprint Planning.   Is the item of such a critical nature that it supercedes all other identified, refined, and prioritized work that is ready to go?   What assurance is there that the time spent during Sprint Planning refining this new item will result in PBI's that meet the Scrum Team's definition of ready?   Keep in mind that the PO has the sole responsibility in Scrum of making the offer to the Development Team during sprint planning.   Therefore, it is the PO's decision whether this new item is indeed critical enough to break up the normal sprint cadence to attend to it, or whether it can be placed as a top priority for the following sprint.

#5 - the Scrum Guide clearly states that the Product Backlog is the sole responsibility of the PO.   While they may delegate, they are accountable.   If the PO becomes unavailable, and the team doesn't have sufficient knowledge/expertise to manage the Product Backlog, it is the PO's responsibility to find someone who is.

Thank you so much, Timothy. Everything is very clear for me now. 

As for questions 2 and 3 - I understand your point, that it is the area, where cross-functional, self-organizing development team should act. However, for me it is still interesting - from the efficiency point of view. Simply to understand.

#1. Does testing really describe product scope? Can it be prioritized by a Product Owner? Shouldn't it be a Development Team consideration, articulated in the Definition of Done, for each release-quality increment?

#2. Planning "too early" would indeed be waste, although a team should be able to forecast how much work is believed to remain in a Sprint. Hence their Sprint Backlog should be decomposed and understood well enough to be sized. The planning of work of a sufficient granularity for execution may be done on a just-in-time basis.

#3. Remember that the actual Scrum role is "Development Team", and not "Developer". What does that tell you about the duty of team members?

#4. What do you think the risks would be, if a Scrum Team tried to negotiate unrefined work during Sprint Planning? In this case, would those risks be justified in terms of the potential benefit to the Product?

#5. The Product Owner is a role. People may come and go but the role does not. In Scrum there must be a clear Product Owner who is competent to perform that role at any given time.

Thank you very much, Ian!

#1 Yes, this "Testimg item" could be included in the Definition of Done in most cases. Then the Development Team should take it into account, while selecting Functional items from the Product Backlog. But if it is some new kind of Testing, which is not conducted on a regular basis and requires even some research spike?

#3 Members of the Team should make decisions in collaboration with each other. So, their duty is to tell member of the Team (who is wrong from their point of view), that this very task is under question and it should be discussed in details. It is about self-organization. 

#4 Risks here are: absence of clear acceptance criteria,misunderstanding concerning content of the PBI under consideration, lack of ability to satisfy the Definition of Done, wrong estimates, lack of opportunity for the Product Owner to contact with stakeholders/customers beforehand and obtain necessary feedback. As a result we can have Sprint failure and dissatisfied Customer. So, from my point of view, in most cases such risks are not justified. But still in rare cases this responsibility could be taken by the Product Owner.