12

Simple question. How do you run the Sprint Review and Sprint planning?

xsace
  • 781
  • 1
  • 7
  • 18
  • Ever heard of conference bridges? –  Jan 04 '12 at 16:39
  • @WyattBarnett no what is it? – xsace Jan 04 '12 at 16:44
  • Conference calls. No excuse for not making a meeting in 2011. Unless you are on an airplane, and that is kinda tenuious. –  Jan 04 '12 at 16:49
  • 11
    If somebody's ill, they are most probably not going to participate in a conference call. –  Jan 04 '12 at 16:53
  • 3
    Why do I have this intense urge to say, "send him a get well card or visit him in the hospital" –  Jan 04 '12 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. –  Jan 04 '12 at 21:32
  • 3
    As a Product Owner, I need to get well, so that I can attend the iteration planning meeting. 5 points. –  Jan 04 '12 at 23:10
  • Related and possible duplicate: https://pm.stackexchange.com/questions/27590/how-should-the-scrum-team-proceed-if-the-po-is-sick-and-cant-attend-the-sprint/ – Bogdan Jul 04 '20 at 12:12

2 Answers2

14

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.

Thomas Owens
  • 19,399
  • 2
  • 33
  • 62
  • 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? – xsace Jan 04 '12 at 16:35
  • @xsAce Documentation? –  Jan 04 '12 at 16:53
  • @xsAce - I Do not know what tool you are using but our tool allows for prioritization the backlog and the icebox. –  Jan 04 '12 at 17:31
  • @Chad We just use post its – xsace Jan 04 '12 at 17:34
  • 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 Jan 04 '12 at 17:44
  • @xsAce - I find it difficult to believe that you can capture all of the information you need to effectively manage a software development project when you use post its to manage your stories,track your progress, and prioritize your work. –  Jan 04 '12 at 18:45
  • @ThomasOwens Thanks, well, the thing is we define all the sufficient story details DURING the planning, not before hand. I mean this is when the transfert of knowledge from the PO to the team happen. That's why I find it difficult to hold a planning without him. I'm not in a situation where we don't have anything to do, there is always room for work, reducing the debt, etc... But to include new stories and hold a new sprint that adds direct value is something I have difficulty to see happen. – xsace Jan 04 '12 at 19:16
  • 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 Jan 04 '12 at 19:32
  • @ThomasOwens While I agree that a missing person shouldn't break the sprint, we are not talking of a team member here. I mean the PO role is critical and REQUIRED by the process. If it could be revisited so easily, we wouldn't need it in the first place. The responsibility would be shared by the team directly. I think the solution is more about company and finding someone to replace the PO temporarly than revisiting the process. But thanks – xsace Jan 04 '12 at 20:05
  • 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 Jan 04 '12 at 20:10
  • @ThomasOwens okay I got your point now. – xsace Jan 04 '12 at 20:11
  • +1 for the key point "...to have an alternative PO that is informed of all decisions and communications, but doesn't actually make decisions unless needed." – MissesBrown Jan 25 '12 at 01:12
  • "Your sprint review can be run by the Scrum Master, who seems well suited to this. 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. A summary can be presented to the Product Owner upon his return." ..... Hey Thomas, did you mean to say "sprint retrospective" here? It sounds like you're talking about the retrospective, not the sprint demo (also known as sprint review). – jmort253 Nov 18 '15 at 11:21
  • @jmort253 In the last scrum team I was on (which was ~9 years ago), they were the same thing. There was 1 meeting at the end of the sprint where the team demonstrated the completed stories and assessed what went right/wrong during the sprint. It was both a product and process review and reassessment prior to sprint planning. Based on other things that I'm reading, combining the demonstration of the product (the review) and review of the execution (the retrospective) into one meeting is not uncommon and is something that I'd encourage to ensure that all stakeholders are present and involved. – Thomas Owens Nov 18 '15 at 12:31
  • @ThomasOwens - From what I've read, the sprint retrospective only involves the scrum team; otherwise, the people may not feel comfortable speaking up about any problems they have, especially if some of the stakeholders are managers, executives, or clients. According to the Scrum Guide, the review and retrospective are separate meetings, and according to Michael James, Mike Cohn, and my CSM instructor, only the Scrum Team (and in some cases just SM and dev team) attend the retrospective. – jmort253 Nov 18 '15 at 12:46
  • [cont'd] - It might be worth clarifying that you practiced a modified version of scrum so that folks don't get confused between review and retrospective when it comes to scrum. Hope this helps clarify, and thanks for your posts. They're helping us a lot in our move towards agile and scrum! – jmort253 Nov 18 '15 at 12:47
  • 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 Nov 18 '15 at 12:53
1

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.

Özmen Adıbelli
  • 11
  • 2