Simple question. How do you run the Sprint Review and Sprint planning?
8
-
Ever heard of conference bridges?– Wyatt BarnettCommented Jan 4, 2012 at 16:39
-
11If somebody's ill, they are most probably not going to participate in a conference call.– quant_devCommented Jan 4, 2012 at 16:53
-
3Why do I have this intense urge to say, "send him a get well card or visit him in the hospital"– HLGEMCommented Jan 4, 2012 at 21:29
-
9@WyattBarnett, there are times when people are not available. I assure you that when my coworker went out sick with cancer she was not able to answer work calls or participate in confernce calls. I was not able to do so when my beloved died. There is no excuse for thinking people are machines who are available 24-hours a day no matter what.– HLGEMCommented Jan 4, 2012 at 21:32
-
3As a Product Owner, I need to get well, so that I can attend the iteration planning meeting. 5 points.– pdrCommented Jan 4, 2012 at 23:10
|
Show 3 more comments
2 Answers
This is something that the project's risk management plan should address. If you haven't identified individuals at either the project or iteration level that are crucial to success and methods to continue work when they are unavailable, this is the perfect time to do so, as soon as the team is around. One of the things that you should do is identify alternates for roles so that no position is one-deep.
In the meantime, the entire team should be able to carry on, for the most part.
The Scrum Master can facilitate your Sprint Review. If you can have any customer or user representative available, that would be beneficial as you demonstrate your features to the stakeholders and receive feedback. Since the Product Owner is not present, it could be a good idea to make a recording of the meeting somehow - a video recording, audio recording, screen capture, and notes - and present them for review upon their return.
If your Product Owner is involved in your Sprint Retrospective, I would also continue that as planned, only without the Product Owner. You are, after all, reflecting on your team's performance and how you handled problems and met successes. The Scrum Master, as the keeper of the process, should be aware of the goals in terms of story points, features, and problems that arose. Again, since a critical stakeholder isn't present, I'd recommend capturing some kind of outline of the discussion and findings.
If your Sprint Review and Sprint Retrospective are one meeting, anyone who is not involved in the process directly should not participate in the retrospective. For example, I mentioned that a different representative of the customer or user group might be a participant in the Sprint Review instead of the Product Owner. If this person has not worked with the team closely, they would be asked to be a silent observer of the retrospective (which may be useful for training them as an alternate Product Owner) or leave the room entirely.
Upon the Product Owner's return, I would recommend that the Scrum Master and perhaps one Development Team member brief them on the results of the sprint review and sprint retrospective. With adequate recordings and meeting notes, the Product Owner should be able to read those and have a short discussion with the Scrum Master and team member if there are any questions or concerns.
As far as sprint planning, the Product Owner's job is to continually update the product backlog with new stories and maintain the priority. At any given moment in time, the product backlog should be prioritized. Your Scrum Master should be able to take historical project data and lead the team in the estimation process of stories. Then, the team can pull down the appropriate number of stories based on previous sprints.
answered Jan 4, 2012 at 16:29
-
I agree for the review. But for the planning, without the PO to give details on the requirements, it can be difficult to interpret an item of the Product backlog right?– xsaceCommented Jan 4, 2012 at 16:35
-
1@xsAce A posted story should have sufficient detail to understand it. Again, it goes to risk management, and there might be some questions, but if you're in a situation where you can make 0 forward progress, something is wrong with how you are running the project.– Thomas Owens ♦Commented Jan 4, 2012 at 17:44
-
2@xsAce I would recommend that the PO continually ensure that the highest priority stories are documented enough so that they can be developed and tested in his absence. Although the transfer of knowledge at a planning meeting is good to get everyone on the same page, I feel that you should have enough information to do something, even if it's preliminary work. If you can't deliver something of value at the end of your scheduled sprint because of a missing person, you need to revisit your process to eliminate that all-knowledge-in-one-person.– Thomas Owens ♦Commented Jan 4, 2012 at 19:32
-
2@xsAce The PO is a member of the Scrum team. A Scrum team consists of the Product Owner, the cross-functional product development team, and the Scrum Master. The PO could, in some cases, also be a member of the product development team. Regardless of who the Product Owner is and what other roles they fill, it's essential that you account for times when they are unavailable and treat this as a risk that has a mitigation strategy. A simple mitigation strategy is to have an alternative PO that is informed of all decisions and communications, but doesn't actually make decisions unless needed.– Thomas Owens ♦Commented Jan 4, 2012 at 20:10
-
1@jmort253 Thanks for that. I'll edit to clarify. And doing some more digging, it seems like the participants in a retrospective may be a contentious issue - some people say that it adds value for a PO while others contend (like you say) that it's for the team only. I'll clarify this answer now. I'd appreciate feedback on the edits.– Thomas Owens ♦Commented Nov 18, 2015 at 12:53
It is obvious that when PO is not available nothing will be same. But of course team should make an effort to decrease the damage to sprint. I think SM should lead the team such that team can work on clarified tasks and leave the unclear tasks to time PO is available. In scrum way, the project continues step by step by leaving some parts to be decided later. So maximum availability is critical.
