Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

7 questions

Last post 02:10 pm November 7, 2014 by Lori Corkum
2 replies
10:17 pm October 30, 2014

Hello,

Please enjoy my somewhat long list of questions. Or don't, it's a free forum.

Background: I’ve read the Scrum Guide, “Scrum - A Pocket Guide”, and the Management Plaza Manual -- hereafter abbreviated SG, SAPG, and MP respectively. I understand SG is always the source of truth, and MP is known to have issues. That said, I have the following questions. Please let me know your thoughts, thanks!

1. SG says: “If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner.”
a. MP says “items (stories) in the Sprint Backlog cannot be added or removed during the Sprint.”? Is MP statement correct, and if so, please me understand what the outcome of SG’s “renegotiate the selected Product Backlog items” might be if not adding/removing PBIs? E.g. is it to increase/decrease the scope of PBIs, without adding/removing any?

2. SG says: “The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team” and also that the Sprint Backlog “belongs solely to the Development Team.”
a. MP says the Product Owner “decides on the contents of the Sprint Backlog.” Is MP correct that the DT, not the PO, decides what goes into the Sprint Backlog? If yes, is there a mechanism (other than common sense) to stop the DT from putting items into the Sprint Backlog that the PO values low in the Product Backlog?

3. SG says: "enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint.”
a. Would it be correct to replace the word “upcoming” with “this”? For example, suppose we’re now in Sprint Planning of sprint 1. The word “upcoming” makes it seem that we are currently forecasting for sprint 2, but I’m thinking really we’re forecasting for sprint 1.

4. SAPG says in 3.7.2 Multiple Scrum Teams that “Each Scrum Team has a Product Owner, Development Team, and Scrum Master”
a. Does this mean you may have two Product Owners and one Product Backlog? My intuition says no, as does MP, which says multiple teams on a single product “should have one Product Backlog and one Product Owner."

5. SG says: “When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.”
a. Might a given team have multiple DoDs at a given time, for example 1 DoD for a PBI item, and 1 DoD for the Increment? (I read two other DoD threads here, but don’t think either addressed this specifically)

6. SG says: "Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
a. Just in case I'm misunderstanding "point of work". I’m thinking this statement is saying inspection should be done while working on a given item, not after building the item. Is that correct?

7. This might be more of a suggestion than a question, but suppose we had a way to collaboratively make questions/comments directly on the text of the SG. I think that would allow questions to be more effectively addressed in their context, and it could be easier for scrum learners to get their questions answered as they read, reducing things like repeat threads (there's probably a scrum principle or two in that). Something along the lines of what genius.com does for some texts. Curious if that’s been considered?

Eric


05:09 pm October 31, 2014

Hi Eric,

I have no knowledge of the management plaza manual, so all my answers will be based on what I know on the scrum framework. Also, I am making assumptions about what you mean with your questions. I would personally throw away the management plaza manual.

1. This basically means the team will make their commitment, but will then task out the PBIs for the sprint. Once they do this, they may come to realize they have taken on too much or have capacity to pull in another story. They will have a conversation with the product owner about what to drop out or what to pull in to the sprint.

2. The PO decides on the priority of everything in the sprint backlog. It is then up to the development team, with collaboration with the PO, on what they pull into a sprint.
For example there are 5 PBIs that the PO has prioritized for the dev team to pick from for the sprint. 1 is the top priority and 5 is the lowest. The dev team only has capacity for 3 items in the backlog, however they make it known that if they do priority 4 first, then items 1 and 2 will be done a lot quicker, than if they were to build 4 after items 1, 2 and 3. Hope I explained that simply enough!
One amazingly simple mechanism to ensure that people are not working on anything that hasn't been prioritized or agreed with the PO is to use a big visible storyboard - large stickies on a wall, right where the dev team & PO sit. It will have everything that is being worked that sprint visible for all to see, so there is no confusion.
Also, it is a good chance to teach the team that the PO has the final say on priority, even if the CEO was to walk over and ask for a 'small change' - they should refer him to the PO. You may also want to ask if they would like to have it is as an item on the teams working agreements.

3. I can see how that might be confusing. I think it means upcoming in the sense that once sprint planning is over, you can get started on the PBIs of the sprint! Also, if you have 4 week sprints, sprint planning is likely to last all day and 'upcoming' may mean tomorrow!

4. One Product owner for one backlog makes sense - it gives a clear direction for the product as a whole and is the best setup to avoid any gaps or miscommunications about what is being built by each team. The PO role is a full time role and is best suited with a 1 to 1 relationship (1 SM, 1 PO and 1 Dev Team).

5. This depends what level you are talking about - for example, a release may have to have the top 50 PBIs DONE, before they can push it to production and have users using the new system/application, in which case the release would be DONE. Also the definition of done can and will change.

6. I think it is driving towards constant collaboration between the PO and Development team. For example, the PO shouldn't be seeing a fully developed story on the final day of the sprint, when it was completed 7 days ago. The PO should look to see if it is what they were expecting as soon as they can. This could also mean if an issue has happened, the best time to inspect & adapt is the moment something happens. No need to wait for the retrospective.

7. No idea on number 7. Although I do know the scrum guide isn't meant to answer all of your questions, but it is meant to provide you with the framework to build upon.


02:10 pm November 7, 2014

I am new to Scrum but I'm seeing conflicts here where I believe some informtion being provided is on Project Backlog and some is on Sprint Backlog. This is going to lead to much confusion. The PO controls PB and the Dev Team controls SB.