This is a simplified/generic version of what usually happens in a sprint, with special focus on the Planning and Review meetings. There was once a time when...

Brian, the Product Owner (PO), presents the Product Backlog (PB) ordered by business value: with highest items first (time=1 in fig 1).

For weeks the PO has had long discussions with stakeholders until he finally reached the decision how to order the PBI (PB items) and now he has the opportunity to clarify the reasons to the developers in front of the stakeholders during the Planning meeting. We can feel transparency in the air, and it looks good! Brian addresses everybody.

- This user story tells how the user can quickly decide how much to refill his account: "as a user I want to log in and go to my account in order to buy credits." Is it clear to you?

The PBI is usually written in user story format, where the story is broken down in 3 parts:

"As a (role) I want/need to (action) in order to (objective)."

Developers have the opportunity to ask questions to the PO and confirm their understanding next to the stakeholders. John, a senior developer, enquires about the feedback and the conversion rate.

- How do you want to proceed once the payment is received? And how should we convert the amount into a certain number of credits?

Brian quickly answers.

- No, we will use currency in the credit system so just show the credit with a dollar sign as with any currency and update the previous balance taking into account the newly received amount.

John is not satisfied.

- No conversion, that is clear. How about the procedure after the money is received?

Leslie, representing Customer Service, looks at Brian as if asking for an opportunity to speak. Brian nods and Leslie answers.

- We need to send the customer a confirmation email and the sooner it gets dispatched the better, else people will start calling us to enquire why the credit is not yet in the system. Time is critical here.

Paul, another developer, chimes in.

- Yes, we understand this is critical so we will use the "fast-lane". That is how we call the message queue to dispatch critical messages. It takes precedence over any normal email campaign work and accesses the email SMTP server almost immediately. You can expect the delivery to happen within 30 seconds or less, depending on the traffic in the network.

Some eyebrows are raised and Josh, the Scrum Master, understands that the message was not fully received so he clarifies.

- The "network" is the internet in general. We have a good connection so there is no risk that the message will be delayed. We use a queueing system with different priorities and this confirmation message falls into the top priority category.

Brian sees that everybody understands the point so he continues.

- I will work with the team to detail all the steps of the payment and confirmation process. For now, I just want to show you what is planned for the next sprint. I have listed these 6 PBIs to complete the order processing system. I would like to name this sprint goal "Closing the order processing system." What do you think?

Josh seizes the opportunity to recommend caution and offer coaching.

- Brian, we understand your target but we still need to review the work involved in these PBIs before we agree that it is possible to do it all in one sprint. I would also suggest to avoid words like "complete" or "closing" in the sprint goal definition because this creates expectations that may not be realistic.

Brian nods in agreement.

- Ok, this may be just wishful thinking from my part, the key point is that we have to target the order processing workflow and close it ASAP so we can deploy it into production. Please understand that without this completed workflow we can't release it in production, it's an all or nothing situation here.

Developers nod in agreement and Paul concludes.

- Ok, Brian, so please let's talk about the other PBIs you consider critical to close the ordering system.

Brian goes on explaining the other PBIs and the conversation continued until the developers were happy. Josh looks at his watch and says:

- Well, we still have some time left so if anyway wants to add something, now it's the best time to do so. Otherwise, I think we can close this part of the meeting and thank the participants. In the second part of this meeting the Scrum team comes back to refine the backlog, is this ok? 15 minutes for coffee?

Brian has to close the meeting.

- Sure, well I would like to thank you all. I expect our next meeting to review the work done will happen in two weeks, as usual, but I will confirm this in the afternoon, after we close this meeting with the developers and decide on the sprint duration.

As the Scrum team reconvenes for the second part of the Planning meeting (time=2 in fig 1), they discuss how to transform a user story into a series of tasks that can be executed in no more than 2 days of work. Figure 2 shows the decomposition process

At the end of the meeting it is decided to accept the first 3 PBIs for the next 2-week sprint and leave the last 3 other PBIs for future sprints.

Paul raises the issue of a pending technical debt. The team agrees that it can be approached as the first two PBIs are delivered because they are critical for the sprint goal. Brian informs that the new item is not going on the PB since there is no direct visible benefit for the users. It is his call, he knows that adding it in the PB would raise concerns unnecessarily among management. The team updates the Sprint backlog (time=3 in fig 1) and closes the meeting.

The sprint work can start with a clear goal in everybody's mind.

Some days into the sprint, Norbert, the junior developer, raises concern with a bug he his not able to trace during a daily standup. John and Paul agree that it may be a difficult issue and offer to help in a mob programming effort with Norbert on the keyboard and the other two experienced developers navigating the debug process. Norbert loves the opportunity to share their insights in real time and appreciate their availability to focus on the bug immediately. This happens because the team takes collective ownership of each and every task: when someone needs help, everybody volunteers to help!The sprint backlog is updated (time=4 in fig 1).

The team bands together to work on the bug. Initially it is expected to be fixed today but it takes longer and now the daily scrum becomes a boring repetition that "we are working on the bug."

Josh asks the team if there is anything he could do to help, but they agree that more time is the only thing they need. Paul suggests that someone should be telling Brian about the delay. Josh volunteers to help with that since it's the scrum master's job to remove impediments and spare the team from the trouble.

- Ok, I can give Brian a quick status report based on what you said so you don't waste time on that but be prepared because probably Brian will attend tomorrow's daily meeting to hear directly from you.

The next day, as expected, Brian showed up and heard everybody. As the 15 minutes time-box elapsed, Brians asks for 5 minutes to close the topic.

He explains that his concern is to keep the stakeholders informed to avoid frustrations. He understands that it is not possible to predict when exactly the bug will be fixed, but he needs something to tell management. John suggests that the last PBI (PBI#3) is at risk and should not be expected by the end of the current sprint. All developers agree and Brian takes note. He thanks the team for their insights and leaves the meeting. He knows that management will not appreciate the news...

Fortunately the bug is fixed in the third day but now the team is a little behind schedule. The team tries to compensate for the delay and pushes hard to try to complete all tasks tied to PBI#3.

When Josh notices that the team stays late every day he asks everybody (including the PO) to a short meeting when he reminds them that the criteria for done are more demanding now and it is unlikely that they will close all the tasks by the end of this sprint.

He also reminds people that it is important to keep a sustainable work pace. It would be better to complete each task according to their rigorous definition of done and to complete all tests of the two PBIs that can be safely delivered. The team agrees and testing is resumed for PBIs 1 and 2.

On the last day of the sprint (time=5 in fig 1) Brian is tempted to have PBI#3 in the increment. He begs to the developers.

- My friends, as I understand you have completed 90% of the last task (task#9) of PBI#3. It would be a pity not to include it.

Josh quickly intervenes before anyone else is tempted...

- Brian, I understand your good intentions to preserve the sprint goal but we can't do that. It's an all of nothing for us. You may inform that we come "that close" but no, we have not "done" PBI#3.

- But Josh, it is so little that is missing... besides, I don't plan to release before all PBIs (1 to 6) are delivered.

- Yes, Brian, I get it but the rules of scrum require that any and all increments be releasable. It is up to you to decide when you release but it is our duty to provide you with what is actually done. Suppose a VP demands an interim release and we are faced with some untested case that blows up in the user's face. How bad would it be for our product's image?

Brian finally gets it.

- It's too risky, I see, let's do the review with PBIs 1 and 2 only. I will not even try to show PBI#3 so please disable any buttons related to it so I don't get mixed up, and let's move on!

The review meeting (time=6 in fig 1) went well since stakeholders were warned not to expect PBI#3 now. They know that work is advanced for this PBI but everybody is concerned with the three remaining PBIs that will allow the release to production.

The stakeholders discussed PBIs 1 and 2 and made some suggestions to the developers that will be handled in the next sprint when PBI#4 is the first in line to be completed.