Skip to main content

Concept Clarification Questions (PO role related)

Last post 08:21 pm August 15, 2017 by Blake McMillan
1 reply
12:24 am August 11, 2017

Hi all,

I am quite new to Scrum. I have followed through this Forum, but have some concept clarification questions in mind (Product Owner role related). Would appreciate some advices from the experts & practitioners in this group.

 

1. When the velocity is behind expectation (e.g. due to external impediments):

a) if a stakeholder/ manager comes, should SM tell him that the velocity is for the sprint work forecast (rather than productivity prediction) & ask him to refer to PO for progress of development?

b) if PO comes, should SM tell him that the forecast scope can't be promised given its emerging nature?

With reference to Scrum Guide statements as below, my view tends to be "Yes" for both a) and b). Am I correct?

- "The Product Owner is the sole person responsible for managing the Product Backlog".

- "...enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint"

- "In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making"

Besides, any suggested good articles for the handling & adaptation in such common scenario (with lagging or over-"commitment")?

2. When stakeholders expect to have more feedbacks after current release, should PO opts for (#a) reducing sprint length, or (#b) stop sprinting so as work on new upcoming requests?

With reference to the following thread, my view is to opt for (#a) to enable faster feedbacks with smaller batch sizes while (#b) might be needed only when the upcoming requests eventually impact the sprint goal. Does this make sense?

https://www.scrum.org/forum/scrum-forum/5817/sprint-length-and-consistency-same-product-backlock

3. For PBL refinements, should PO work with DT inside or outside the sprint?

With reference to Charles'article, my view is that PO & DT should collaborate for PBL refinements on PBI details upon ongoing basis, but I'm not quite sure whether this is regarded as outside the "current" sprint (given this is for the upcoming sprints). Or is this inside each sprint but for future sprints? Any advice?

http://www.scrumcrazy.com/The+New+New+Product+Owner

4. If the PBL order does not come to a consensus even close to the sprint planning end, should SM suggest DT to get better prepared (e.g. further clarifications with PO) & restart sprint planning prior to sprint execution? Or alternatively, should DT forecast the most likely PBL then life goes on?

My view tends to be the former one, because DT should have mutual understanding with PO & minimize predictive planning, so as to avoid wastes in sprint execution. Adaptation at retrospective is also needed. Is my understanding correct?

5. For system performance issues, PO should raise to and work with DT regarding how to improve performance and have more robust DoD. Is this correct?

With reference to various threads about NFRs, my view is that PO owns the requirements/ standards while DT owns the DoD.

6. To figure out architecture issues, should PO add this to PBL for estimation & execution together with some features in early sprints? Or alternatively, should this be handled even before starting Scrum and then later in time-boxed sprints?

With reference to various threads about emergent architecture, my view tends to the former one due to transparency & adaptation while the latter one seems more like Sprint 0 which is antipattern. Is my understanding correct?

Thanks a lot!!


08:21 pm August 15, 2017

Hi LK,

You have lots of questions packed into this post!

1. Velocity isn't the measure of team performance in a sprint...producing a high quality product increment during the sprint is the measure.  Keep in mind that velocity measures are subjective values and they help the Dev Team use historical data in Sprint Planning to produce the Sprint Goal.  Stakeholders should be interested in the value and frequency of product increments that are released in Production.

2. Help me understand "more feedbacks".  Do you mean more adjustments to the product increment that was released?  Both of your suggestions are bit alarming to me.  Stopping a sprint is not something you should consider lightly.  The only reason you would do it is if business changes made it so that the sprint goal would produce zero value or even negative value (meaning the product would be harmed by completing)...even a "zero value" sprint could have value in the team accomplishing their goal and learning on the way.  It would also matter how long our sprints are and how close to finished we were.  The other thing you said was reduce sprint length (which is something the SM should do...not the PO).  The main driver for taking that action is business volatility or potentially minimizing risk with teams that are not producing well.  Changing sprint duration will be very disruptive to the team though and it will likely cause them issues with meeting their Sprint goals.

3.  This is no "outside the Sprint".

That's all I have time for now...hope that helps.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.