Why Just Saying "Good Job" Might Be a Bad Idea

Have you been to a Sprint Review where someone sings out, "good job"?

When this happens we might feel happy or encouraged to continue doing whatever it is we did in the review but what does this comment really mean? The idea that someone calls over their shoulder "Good Job" as they leave a meeting, can leave the team in a slight quandary, what exactly was good?

Scrum Teams need to be able to improve in areas where improvement is warranted. Having constructive criticism is healthy for the team and can help them focus on improving whether that be taking a valuable behaviour or practice and making it better or re-thinking actions and activities that don't add much value. The key is getting valuable feedback. For the Scrum Team, it's important to get as specific as possible about what someone thought was good (or in need of improvement) but more importantly, is why they thought to mention it in the first place.

Understanding why is arguably more important than the what in two aspects: 1) it can bring the Scrum Team insight to what the stakeholder values and 2) it can inspire the Scrum Team to design and build better solutions to meet stakeholder expectations of valuable software. For example, if a stakeholder says they liked the demo segment of the sprint review because it showed an easy way to make a credit card payment, the Scrum Team might conclude that the stakeholder values simplicity in the user experience. The Scrum Team might also conclude that in the future, they'll put a little more attention in the UX design to exploit simplicity.

Scrum Teams need feedback to self-improve and need to find the best way to get the gather this information. The easiest way is for the Scrum Team to listen for all stakeholder comments during any of the team's Inspect & Adapt events (daily standup, sprint planning, sprint review). The team may need to follow up with the stakeholders to understand the what and why of their statements. Through the practice of 'Active Listening' and developing a deeper understanding of stakeholders intent, the Scrum Team can improve and provide greater value to the team's customers and stakeholders.

Tweet

Sprint Review Facilitation & Customization

The Scrum Sprint Review is a key Inspect & Adapt meeting where the Scrum Team discusses with Users, Customers, and Business stakeholders what was "Done" in the just completed Sprint. The Sprint Review meeting is short but must cover the agenda items listed below. The attendance by the Scrum Team is required. Attendance by stakeholders is optional but should be strongly encouraged for those key stakeholders most affected by the Sprint results. This article gives some advice on how to conduct the Sprint Review when stakeholders are unable to physically be present.

 

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint and the Product Backlog is amended if needed. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. The Product Owner provides the stakeholders the likely completion date for the release based on the Development Team's velocity and work remaining in the Product Backlog. This is an informal meeting, and the presentation of the Sprint results is intended to elicit feedback and foster collaboration.

 

One hour Sprint Review Agenda includes the following elements:

• The Product Owner identifies what has been “Done” and what has not been “Done” (suggest 5 minutes)   
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved  (suggest 10 minutes)
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment  (suggest 15 minutes)
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date  (suggest 10 minutes)
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings  (suggest 20 minutes)

 

The feedback from the stakeholders, directed toward the Product Owner and Scrum team, is the most important thing to get out of the Sprint Review. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

 

Customization for Stakeholders who cannot be physically present at the meeting

A Scrum Team strives to ensure the key stakeholders, as identified by the Product Owner, are in attendance at each Sprint Review. The key stakeholders identified may differ from Sprint to Sprint based upon the work selected in each Sprint, but it is important to the success of the project that those identified feel compelled to attend the Sprint Review when asked. When a stakeholder cannot be physically present at the Sprint Review meeting, the Scrum Team loses out on viewing subtle hints on the reception of their Sprint results and future Sprint plans. Stakeholder body language and tone are indispensable clues to the observant Scrum Team which can be lost when stakeholders are not with the team during the Sprint Review. Unfortunately the realities of the business means that stakeholders are distributed across several locations and cannot always be physically present at the Sprint Review. Below are the options in order of preference.

 

Telepresence:

 

Telepresence is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend. Scrum Master would schedule the telepresence rooms locally and at all remote locations if possible. The Sprint Review meeting should be conducted as if all people were in the same room.

 

Advantages:

• Stakeholder sees what those present in the meeting room see
• Stakeholder is not a disembodied voice but a real person
• Scrum Team and other meeting attendees can see and gage stakeholder's reactions to product demo and artifacts
• Scrum Team and other meeting attendees can see and gage stakeholder's reaction to comments, statements, and suggestions
• Facilitator of the Sprint Review can better steer the Sprint Review back to the Sprint Review agenda when necessary
Disadvantages:

• Difficult to overhear side conversations from remote stakeholders

Webex / LiveMeeting / Net Meeting / or other online collaboration tool:

 

Online collaboration tool is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend and access to a telepresence room isn't available.

 

Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.

Advantages:

• Stakeholder most often see what those present in the meeting room see
• Stakeholders can follow and participate in discussions on the just completed work shown in the demonstration


Disadvantages:

• All stakeholders will need the same online collaboration tool installed and available
• Higher likelihood that remote stakeholders will talk over people in the meeting room
• Higher likelihood that people in the meeting room will talk over the remote stakeholders
• Easier to mis-read voice inflection and tone without seeing the body language
• Difficult to overhear side conversations

Speakerphone:

 

Using only a speakerphone (no video link or web sharing) is the last option available for stakeholders who don't have access to collaboration tools and no access to telepresence equipment.

 

To give the stakeholder a voice in the Sprint Review, the Scrum Master or Product Owner, as appropriate, would ask those who are remote to provide their input before the Sprint Review meeting so the Scrum Team and stakeholders at the meeting can review their input together. This way the remote teams know that their input counts and will heard by all people in the room.

 

Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.

 

Advantages:

• Remote stakeholders have a proxy voice in the Sprint Review


Disadvantages:

• Speakerphone stakeholders will not see what's being presented
• Speakerphone stakeholders will find it difficult/impossible to follow discussions during the product demo and presentation of any related artifacts
• Speakerphone stakeholders may find it difficult to collaborate with those in the meeting room without seeing the Sprint results
• Higher likelihood that remote stakeholders will talk over people in the meeting room
• Higher likelihood that people in the meeting room will talk over the remote stakeholders
• Easier to mis-read voice inflection and tone without seeing the body language
• Difficult to overhear side conversations

 

 

Tweet

Definition of Done: How to Ensure Compliance

Near the end of the Scrum Guide, there’s a section on the Definition of “Done”:

When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Who is everyone? Everyone includes the Product Owner, Development Team, and Scrum Master although key customers, sales, product management, product support, and managers should also be aware of what the team understands 'Done' to mean.

 

The Scrum Master ensures that a definition of done exists for the scrum team.

How to Define 'Done' for Your Scrum Team

Chris Sterling of Sterling Barton, (www.gettingagile.com), has written an excellent paper on "Building a Definition of Done". Chris Sterling has identified a four step process toward getting a definition of done. These are:

1. Brainstorm – write down, one artifact per post-it note, all artifacts essential for delivering on a feature [user story], iteration/sprint, and release
2. Identify Non-Iteration/Sprint Artifacts – identify artifacts which cannot currently be done every iteration/sprint
3. Capture Impediments – reflect on each artifact not currently done every iteration/sprint and identify the obstacle to its inclusion in an iteration/sprint deliverable
4. Commitment – get a consensus on the Definition of Done; those items which are able to be done for a feature [user story] and iteration/sprint

Let’s assume you have your definition of ‘Done’ documented in a team charter or some other means and have it properly displayed on your scrum board for all to see.

 

Now What?

 

Complying With The Definition of 'Done'

 

In the sprint planning meeting, the Scrum Master should get the Scrum Team to re-confirm their commitment to the team’s definition of ‘Done’. This ensures that everyone on the Scrum Team, which may include new people to the team, is aware and understands what ‘Done’ means. It’s possible that the definition of ‘Done’ had changed during the last sprint’s Retrospective, maybe to tighten up on the quality goals. The Scrum Master goes through the definition of ‘Done’ with the Scrum Team and everyone re-affirms their commitment to it.

 

During the sprint, everyone on the Scrum Team is responsible to follow and adhere to the definition of ‘Done’. It is the Scrum Master’s responsibility to ensure the other members of the Scrum Team (Developers and Product Owner) have been coached and trained to do this. If the Development Team and/or Product Owner are not following the definition of ‘Done’, we hold the Scrum Master accountable.

 

What should happen if the Scrum Team cannot follow one of their definitions of ‘Done’ to the letter? Let’s assume for the moment that a Scrum Team has the following definition of ‘Done’ for a user story:

• Acceptance tests written covering all acceptance criteria.
• Acceptance tests and regression tests run and pass.
• Acceptance tests results reviewed by the Product Owner.
• No known introduced bugs.
• Product demo’ed with Product Owner.
• Product documentation, technical and user, updated.

The Scrum Team works hard following the definition of ‘Done’ and is successful except that they’ve introduced some new bugs, violating the ‘no introduced bugs’ clause of the definition and the sprint ends today. What should happen? This is where the Scrum Master might need to hold back the torrent of people, (managers, sales, product management), all of whom want those stories now! Strictly speaking, the user story or stories that introduced the new bugs cannot be considered ‘Done’ and the story(s) are not demo’ed in the sprint review. However, during the sprint review when discussing what didn’t get ‘Done’, the offending user story bugs might be discussed and stakeholders and Scrum Team alike may determine that the bugs are of little importance to the end-users. (Why this didn’t happen before the end of the sprint is another matter that the Scrum Team would analyse in the Retrospective.) The user story would be added to the next sprint to be integrated into the ‘Release’ branch, probably re-tested, and the insignificant bugs closed as ‘not a problem’. It’s most likely that the Product Owner will have the user story ‘Done’ within 24 hours of the sprint review and can then release it at their leisure. If the bug is significant but the stakeholders and Scrum Team determine that the bug is of little importance to the end-users now, the bug could become a new user story to be addressed later. (You'll note that this second scenario is actually adding to technical debt.)

 

The whole point here is that the definition of ‘Done’ should stand uncompromised throughout the sprint. If there’s a problem with the definition of ‘Done’ that came out during the sprint, it should be addressed during the sprint Retrospective and any changes to the definition made and agreed to there. However, the Scrum Team should heed the words in the Scrum Guide which say, “As Scrum Teams mature, it is expected that their Definition of ‘Done’ will expand to include more stringent criteria for higher quality”. This means that the definition of 'Done' should be strengthen rather than weaken as time and sprints go by.

Tweet