SSW Foursquare

Rules to Better Scrum - 63 Rules

Ready to revolutionize your project management? Check SSW's Scrum and Agile Methodologies consulting page.

Learn more about Scrum with Azure DevOps and GitHub.

  1. Getting Started - Do you know the Scrum guide?

    Everyone who will be involved in Scrum (pigs and chickens alike) should have read and understood the Scrum guide.

    Understanding the concepts of Scrum is easy... implementing it is hard!

    Figure: It's handy to know who the pigs and chickens are. The word "commit" and this silly chicken and pig story, were removed from the Scrum Guide 2011

    Everyone should:

    1. Read the Scrum Guide.
    2. Take the Scrum Open assessment and get at least 85% to be “Certified Scrum 1”
    3. Watch the awesome video:

    Video: Intro to Scrum in Under 10 Minutes (9 min)

  2. Do you know the 8 Steps to Scrum?

    Scrum is easier than it seems, we'll explain how in these 8 simple steps.

    Video: 8 Steps To Scrum - Scrum Explained (4 min)

    Figure: This Scrum image includes all the important steps from the Initial Meeting to the Sprint Review and Retro

    Print out the SSW 8 Steps to Scrum PDF and put it on your "War Room" wall.

    1. Initial Meeting

    In the Initial Meeting, the Product Owner explains the product vision. The Developers think about the Architecture needed and how long they will need to come up with an estimate.

    2. Backlog Construction

    The next step is Backlog Construction, also known as a Specification Review. The Developers propose a high-level software architecture and a to-do list called the Product Backlog. The required features are broken down into Product Backlog Items (PBIs for short).

    These PBIs are estimated and, before a dollar figure is presented, a buffer is added for generic tasks such as DevOps, Testing, Bug Fixes, Project Management, etc.

    This is also when the Product Owner 1st defines the Product Goal (aka the "why" of the project), although this can and should be refined throughout the project.

    A quick note, there are only 3 roles in a Scrum Team, The Product Owner (the boss), the Scrum Master (a kind of project manager), and the Developers (who do the work).

    3. Sprint Planning

    The Sprint Planning session is for the Developers to focus on the subset of the Product Backlog that they think they can complete in the next Sprint, (which is most commonly a 2-week timebox).

    The Product Owner puts the PBIs into priority order and makes sure the top ones have enough detail to be worked on. The Developers then pulls PBIs from the top of the Backlog and commits to delivering as much as they forecast they can, in the coming Sprint.

    The Developers and Product Owner together then define the Sprint goal, (aka the "why" of the Sprint).

    4. Sprint

    The Developers work on features in priority order, having done a Daily Scrum and sending 'Done' emails once the 'Definition of Done' is met. A task board is often used. During this process, the team also refines items in the Product Backlog to ensure they conform to the 'Definition of Ready'.

    5. Product Increment

    Each Sprint is a potentially shippable Product Increment, and with good DevOps, including automation of deployment and testing, this can be done on a "PBI by PBI" basis. This means each feature worked on can be in production as soon as it is finished.

    6. Product Feedback

    Product Feedback will then come in. Some will be bugs, and some will be small changes that can be added to the current Sprint. Other suggestions should be approved by the Product Owner and then added to the Product Backlog.

    7. Sprint Review

    At the end of the Sprint, there is a Sprint Review, where the Developers demo or play done videos of the completed PBIs. The goal is for the Product Owner to understand the increment and to discuss the feedback to make the product better. This is the real measure of success of the Sprint.

    8. Sprint Retrospective

    Lastly, there is the Sprint Retrospective, and this is the best part! The Scrum Team discusses what went well, what didn't, and what to improve, always inspecting and adapting.

    From here, another Sprint Planning session commences, and the wheel keeps turning, getting better and better with every revolution.

  3. Scrum Master - Do you schedule the 3 meetings?

    The Scrum Master plays a key role in the Scrum framework by scheduling and facilitating 3 crucial meetings: the Sprint Review, Retrospective, and Planning. These meetings are essential for reviewing progress, reflecting on performance, and planning future work, helping the team stay aligned and continuously improve.

    The Scrum Master should estimate how much time each meeting will require, then schedule a single calendar appointment to cater to the 3 meetings. When scheduling the calendar appointment, keep in mind the following:

    • Ideally, each of the 3 meetings should be time-boxed to an hour for every week of their associated Sprint
    • This timeboxing does not mean the whole time will be taken up, just that you should not let the time for each meeting be exceeded
    • With the Product Owner's help, the Scrum Team will need some time to update the Product Backlog after the Retrospective and before the Planning meeting
    • People need breaks
    • The Sprint officially finishes at the end of the Sprint Retrospective meeting. The Sprint Planning meeting marks the beginning of the next Sprint
    • These meetings do not necessarily have to be held on a Friday or Monday. You can have a Sprint starting/ending on any day of the week

      • In fact, mid-week meetings are recommended so that the likelihood of it occurring on a public holiday long weekend is minimized
    • Since these meetings will occur every Sprint - set a recurrence on the calendar appointment (every 1, 2, 3, or 4 weeks) so that people have the time blocked out well in advance

    Tip: It can be helpful to finish the Sprint Planning meeting with the first Daily Scrum.

    Schedule the meeting and invite the Scrum Team and any interested stakeholders.

    Figure: Good example - Copy this appointment template and send to the Scrum Team

    Screen Shot 2020 04 06 at 4 15 50 PM
    It is a great idea to run your Scrum meetings through Microsoft Teams, so that the whole team is invited and new developers can easily find the meetings

    See Meetings - Do you know when to send an Appointment or a Teams Meeting? for more information.

    In Scrum, there are 4 meetings in total that you need to know about:

  4. Do you know what happens at a Sprint Review meeting?

    This is the meeting where the Product Owner accepts or rejects the stories in the Sprint and the Sprint itself.

    The Team, having prepared for the meeting, presents the stories to the Product Owner.

    One person, often the Scrum Master, presents a summary to the Product Owner of the stories committed at the Sprint Planning meeting and the stories being presented for acceptance.  The Team seeks to have more stories accepted than originally committed.  It is important that the Product Owner knows at the beginning whether The Team believes that they have over or underachieved the Sprint Goal.

    Each story is then presented by the Team for acceptance. They aim to get the Story accepted as quickly as possible (aka tick and flick) while being totally transparent, which includes declaring whether there are any known outstanding bugs (which should already be on the Product Backlog) and adherence to the Team's Definition of Done.

    Video: Explaining a PBI to a Product Owner with Jake Bayliss (5 min)

    Note: If there are additional stakeholders, make sure they are also in the loop and up to speed on the current increment.

    If a Story is accepted, but more work needs to be done, a new Story to cover this work is added to the Product Backlog.  Similarly, if a bug is found during the review, it is added to the Product Backlog.

    If a Story is rejected and returned to the Product Backlog but the Sprint itself is accepted, then a careful decision needs to be made.  If changes have been checked-in to the Sprint's branch then it must be established that these changes have no adverse effect or they must be carefully undone before the branch is merged with the trunk.  For this reason, it is always safer to accept stories with conditions rather than reject them.

    The Scrum Master keeps the meeting on track and to the Timebox by disallowing discussions not relevant to the acceptance or rejection of the story; this is often done by making a note to bring the subject up again in the Retrospective Meeting.

    This meeting is normally timeboxed to as many hours as there are weeks in the Sprint.

    It's important that stakeholders stay in the loop of the projects progress, but they are often too busy to join the Sprint Reviews. Before the summary, you should try loop them in and if they cannot join, record the summary and send a link.

    In Scrum, there are 4 meetings in total that you need to know about:

    What if you can't attend the Sprint Review

    Golf holiday
    Figure: Playing golf

    If you can't attend your team's Sprint Review (e.g. you're on leave, working part-time, or in a different timezone), you should give the team a summary of where you're at, so they can inform the stakeholders on your behalf.

    • Send a brief "Sprint Review" email to the team to provide them with an update on the status of your tasks. This will enable the team to pass on the information to the client.

    Not doing Scrum?

    Even if your client does not want to do Scrum (they might have had a bad experience in the past) you should still do this step, just under a different name. E.g. "Hey Bob, let’s schedule a catch up on Friday. Then I'll show you what I have done this week".

  5. Do you know what happens at a Sprint Retrospective meeting?

    At the end of every Sprint, the Development Team performs a Sprint Retrospective, also known as the Retro. The Retro provides an opportunity for the Scrum Team to reflect on what has gone well, what has gone poorly, and what the team wants to change.

    Inspect-and-adapt is a key component of the Scrum framework and the Retro gives Scrum Teams an opportunity to learn from their successes and mistakes.

    The Retro is a time-boxed event that focuses around 3 questions:

    1. What went well?
    2. What didn't go well?
    3. What will we do differently in the next Sprint?

    The Scrum Master facilitates the meeting and collects issues as they are raised. Once every Scrum Team Member has spoken, he facilitates debate on each issue so that team consensus is achieved. The result should produce an actionable outcome, for example:

    • An adjustment is made to the daily processes followed by the Scrum Team
    • An adjustment is made to the Definition of Done
    • An adjustment is made at the organization level
    • An item is added to the Product Backlog

    To help aid discussion, it can be useful for the Scrum Master to prepare items for review by inspecting the Sprint Backlog and statistics such as:

    • Velocity
    • Burndown
    • Code Coverage
    • Number of deployments
    • Number of errors in Application Insights
    • The Product Roadmap - to see how well the team is doing at achieving the high level strategy.

    As an example, the Scrum Master can find PBIs (Product Backlog Items) in the Sprint that were successful/not successful and then facilitate the discussion to find the reasons.

    retrospective meeting 1
    Figure: The Scrum Master can inspect the Sprint Backlog for items which are "Not Done" at the end of a Sprint

    retrospective meeting 2
    Figure: The Scrum Master can inspect the team’s velocity over multiple Sprints

    retrospective meeting 3
    Figure: The Scrum Master can inspect the team’s Sprint Burndown for insight into how work progressed through the Sprint

    retrospective meeting 4
    Figure: The Scrum Master can inspect the team’s Code Coverage for an insight into code quality

    Once all issues have been discussed to the satisfaction of The Scrum Team, the meeting concludes.

    If the timebox limit is reached, the remaining issues should be recorded and dealt with by the Scrum Master. Any outstanding issues must be raised at the next Retrospective if they are still relevant.

    The timebox for this meeting is usually as many hours as weeks in the Sprint.

    Using interactive tools (Apps)

    The goal is to make Retro sessions as engaging and insightful as possible. There are 2 main options:

    The advantages are:

    • Interactive - app participants can access the board (not one person writing an email, while others watch)
    • Participants can upvote and downvote specific items on the Retro
    • Participants can add items to the board
    • Participants feel more engaged with the process
    • You can leave the board open (if some people have missed the Retro, they can add items afterwards)
    • After you close the board, participants still have access to the Retro and can see what happened

    retrospected bad
    Figure: Bad example – This is a paste from the tool, but the action points are unclear

    retrospected good
    Figure: Good example – This is a paste from the tool, but with the modifications at the end, the action points are clear

    In Scrum, there are 4 meetings in total that you need to know about:

  6. Do you know what happens at a Sprint Planning meeting?

    The work to be performed in the Sprint is planned at the Sprint Planning meeting. At the Sprint Planning meeting, the following 3 questions are answered:

    • Why is this Sprint valuable?
    • What can be delivered in the increment(s) resulting from the upcoming Sprint?
    • How will the work needed to deliver the increment(s) be achieved?

    Why is this Sprint valuable?

    The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

    What can be delivered in the Increment resulting from the upcoming Sprint?

    The Architecture Review should be conducted every few Sprints prior to the Sprint Planning to determine any tech improvements that can be implemented in the project.

    Technical Debt should be considered prior to the Sprint Planning, as it is imperative to address it. Just Enough Refactoring should be used to solve the debt that directly surrounds or is impacted by the features included into the Sprint.

    The Product Backlog is examined, and the Product Owner makes changes so that it is prioritized, with bugs prioritized among the Product Backlog Items (PBIs).

    The Product Owner is then asked to group the top-ranking bugs into PBIs for inclusion in the Sprint. See this rule.

    The team are then advised of their resourcing for the Sprint as there may be additions, subtractions, leave or public holidays which are different to the previous Sprint. Considering their previous record and their current resources, The team decide on the number of story points that they will deliver in the forthcoming Sprint. When the team are not currently co-located this is often done by voting, and discussed until consensus is reached.

    The team then size (assign Story points to) PBIs starting at the top until there are more than enough PBIs to fill the Sprint.

    The process of sizing is somewhat formal. Either using cards or IM (essential if not co-located) the team vote privately on the size of the PBI. They can either:

    • Use t-shirt sizes of XXS, XS, S, M, L, XL, XXL and XXXL or
    • Their equivalent number of story points for which we use the Doubling Series of 1, 2, 4, 8, 16 or 32.

    Once the differing votes are in, the Scrum Master asks the smallest and biggest voters to explain the reasons for their vote. Assumptions and omissions are quickly identified through discussions and the Scrum Master encourages discussion until consensus on the story points is reached. Any PBI voted at 16 or higher should be broken down into smaller stories; re-prioritized by the Product Owner and re-sized if necessary.

    Figure: A sample PBI in Azure DevOps

    Once enough stories are sized, the Product Owner is given the opportunity to re-prioritize now knowing the relative sizes. If more PBIs need then be sized then they are. The Scrum Master keeps everything going and facilitates negotiation between the team and the Product Owner until final priority is confirmed and the team commit to a number of stories and the meeting concludes.

    This meeting should be timeboxed to an hour for every week in the Sprint. However, the Scrum Master must be sensitive to the meeting producing a workable result.

    Capacity Planning

    It is important for Sprint capacity planning to be consistent across all teams. As such, there should be consistency in how many story points you allocate to a Sprint. It's unreasonable to think that someone will be able to work productively and consecutively for 8 hours straight on a particular task. For example, if a task is allotted a 4 for effort (8 hours), the developer will probably spend about 6 hours coding, and 2 of those 8 hours fixing bugs, communicating, or working on the admin side of things. Even if devs may try to factor these things into their estimation, a 20% buffer never hurts.

    Therefore, a standard 1-week Sprint with 2 resources would have about 32 story points allocated.

    Note: This is specifically for the first couple of Sprints in a project, until you get an average velocity that you can use for capacity planning moving forward.

    How will the work needed to deliver the Increment be achieved?

    To answer the second question the team create tasks, with sub-tasks where necessary, for everything that needs to be done to implement the PBI. Every task and sub-task should be given an estimate in hours and the same value placed in the Remaining field.

    No actual work on the Sprint should start until this planning is complete. It is these Remaining hours that determine the first value in the burndown chart which sets the Sprint on its way to completion. There must be no omissions or the team will start without an accurate burndown and we all know that "The team is nothing without a burndown".

    The team should also ensure that the burndown chart is working and will be automatically sent to all members of the Scrum team overnight.

    The meeting concludes when the team reports to the Scrum Master that their planning is complete and they are able to display the burndown chart.

    Ideally this meeting is timeboxed to as many hours as there will be weeks in the Sprint. However, the Sprint Planning is so essential that it must continue to completion outside the meeting if necessary.

    It is not essential for the Product Owner or the Scrum Master to be present for the whole meeting but they must be available for consultation. The Scrum Master should formally close the meeting.

    Once this meeting is finished, the Scrum Master should email the Product Owner with a forecast.

    In Scrum, there are 4 meetings in total that you need to know about:

  7. Methodology - Do you do Daily Scrums (aka stand-up meetings)?

    Tight project teams have a Daily 'Scrum' every day at the same time.

    It was once called a 'stand-up meeting' but that discriminates people in wheelchairs.

    It is best to have it standing up, so it's short and to the point. No-one wants to stand around waffling.

    Everybody knows the 3 essential questions:

    1. What did you do yesterday?

      • Including having Azure DevOps (or other task tracking system) up-to-date
    2. What are you going to do today?

      • Make sure the task board has your current task "In progress"
    3. Do you have any roadblocks?

      • Explaing issues/impediments

    Asking these questions of every team member means no-one can hide and everyone remains connected. Further, you can notice what was promised and what was performed. This enables the team to discover issues quickly and keep abreast of the progress.

    The team's successes and failures are shared, and anyone who knows the answer to someone else's problem can help with a solution, after the meeting.

    Video: Watch a Daily Scrum at Microsoft (short - 4 min)

    Video: Watch a Daily Scrum at Microsoft (long - 12 min)

    "Great video guys. Remember, it is ok to change Scrum, actually, it is necessary for success. Just adhere to the values of Scrum." Stephen Forte (Board member

    Follow these essential tips to improve your Daily Scrum meetings:

    Tip #1: Be prepared for the meeting

    Before you join the Daily Scrum, check the group to see what your colleagues have been discussing and working on, and check the portal to confirm the meeting time. If you’re joining a new project or re-joining a previous one after some time away, these steps are important to keep yourself up-to-date and abreast of progress.

    Then you’ll be able to say to your Scrum Master: “I've had a look at the Teams group. I am ready to join the daily Scrum”.

    Tip #2: Have your Scrum Master to review the Sprint progress at the end

    At the end of the Scrum, the Scrum Master should review the current burn down to check on the progress of the team.

    burndowntfspreview 1710232021943
    Figure: A burndown chart in

    Tip #3: Keep a schedule of the Daily Scrum times on a wall (+ have a recurring appointment in Outlook)

    Figure: Schedule a recurring Daily Scrum meeting in Outlook using this template

    teams meeting daily scrum
    Figure: Or you can use Microsoft Teams

    Tip #4: Keep to the schedule - Same place, same time (even if people are missing)

    Get started on time. Especially in the beginning, people will be late, but the meeting should be held with the remaining people. Don't worry. People learn.

    If the Scrum Master is not a full-time member of the team (often they are), they should attend every now and then to check the Scrum process is being followed and the Daily Scrums are being used synchronize the team and not a general meeting.


    • The Product Owner (often the client) is not required at the stand-up meeting. If they wish to turn up, remind them that they have tape stuck over their mouth, so they don't talk
    • If you are not doing an approved Sprint and doing ad-hoc work, then best if the Product Owner (aka client) attends (see Ad Hoc work)

    Tip #5: Update tasks before the Daily Scrum

    Daily Scrums are more effective when team members arrive when their tasks are already updated.

    See Do you update your tasks before the daily stand-up meeting?

    Tip #6: Don't go into detail

    Keep your answers short and concise. Do not stray from the 3 main questions. Don't let your Daily Scrum become a general meeting.

    Remember to use the "Parking Lot", the place for any discussions that stop the Team from answering the 3 main questions. Only interested people stay for the "Parking Lot" to discuss issues after the Daily Scrum.

    Tip #7: No phones + no checking email - No distractions

    Technology in the Daily Scrum causes people to lose focus on the goal. The goal is for the team to synchronize by sharing what they are doing. Avoid giving people the opportunity to be distracted easily by forbidding email, SMS and mobile phones from the Daily Scrum.

    Tip #8: Use a task board (even better use an electronic one)

    A task board allows people to visualize what the team is talking about.

    tfspreviewtaskboard 1710232021943
    Figure: A Task Board from Azure DevOps

    Tip #9: Carry a pen and paper

    Use a pen and paper to jot things down. A whiteboard is also great for "Parking Lot" topics that arise, to be discussed after the meeting.

    Tip #10: If you have raised impediments, consider contacting the Product Owner

    Often the Product Owner won’t be at the Scrum. However, call the Product Owner if you have an impediment (aka roadblock). Communication with the Product Owner is essential and if you haven't touched base with him in the few days, then do so. A disconnected or absent Product Owner is a sign of dysfunction.

    ProductOwnerTelephone 1710232021942
    Figure: Call the Product Owner if you have an impediment

    Tip #11: Store Daily Scrums in the Teams team so the PO can easily access it

    Sometimes, the Product Owner will want to see the Daily Scrum for many teams. Adding them to every meeting would create lots of noise in their calendar. Instead, make the Teams meetings easy to find so they can locate the Daily Scrum for any project via the Teams team.

    daily scrum bad
    Figure: Bad example - Too many Daily Scrum appointments

    daily scrum good
    Figure: Good example - Make Daily Scrums easy to find via the Teams Channel Calendar

    Tip #12: What to do when you're working for a PO directly

    If you don't have a team, and you're doing ad hoc work for a PO directly, it's best to contact him for the Daily Scrum every day if possible, and follow up with an email. This will keep the 2 of you synchronized.

    Tip #13: How do you enter Scrum meetings into your timesheets?

    Once you have completed your stand up, add “S” to your timesheet as per Rules to Better Timesheets.

    Tip #14: Send an email

    To prevent misunderstandings or potential disagreements, send your Daily Scrum update via email. This ensures that everyone on your team is aware of your current tasks, even if they were unable to attend the meeting. 😊

    Note: Be sure to include the project name in both the subject line and the email content, as people often read the message without referencing the subject.

    Figure: Good example - Always include what you previously worked on and what you plan on doing today

    Tip #15: Use IM

    After you have sent your email, you can also make it front and center by sending them a ping on IM.“Check your email for my Daily Scrum” or paste in the below (a lightweight version with only what to do).

    Use Teams or Skype to bridge gaps in geography.

    Focus on the Flow

    "Extend this rule to focus on 'flow of value', not just people. In a continuous flow mindset, the daily standup is less about the people... it's about flow. The team faces the Scrum board and goes ticket by ticket for all the items in the 'work in progress', finding out what is needed to get it to the next stage... respecting work in progress constraints." Joel Semeniuk

    When using email or IM try to be brief and as specific as possible:

    Hi Bob,

    I have XX days until my next client booking. I have XX emails in my inbox. Yesterday I was on sick leave.

    Today I am working on:

    • Timepro PBIs
    • Tidy inbox

    Figure: Bad example - Lack of details. E.g. Yesterday - if it's Monday, you wouldn't say “Yesterday was Sunday"... so if you were sick, it's more useful to go back to the prior day you were working

    Hi Bob,

    I have XX days until my next client booking. I have XX emails in my inbox. Last Friday I was on sick leave.

    Today I am working on:

    • TimePro - Adding new button to the next day
    • Getting my emails on "" to zero

    Figure: Good example - Clear details

    Tip #16: Auto-generate your Daily Scrum with AutoScrum

    AutoScrum will scan your Azure DevOps repositories and find all the PBIs that you worked on yesterday and that are In Progress today.

    More details:

    More information

    What should I do when blocked?

    When you are blocked, you should ideally take steps to unblock yourself. However, you should know when to ask for help and understand what mode of communication is best for your task.

    The ideal people to ask for assistance are:

    • A fellow Developer that is Senior or knows the tech
    • Your Scrum Master who can reach out to the Product Owner when issues reach beyond developing your project

    What happens when you run out of tasks?

    The goal is to be productive for 8 hours of the day, so communicate with the rest of the developers and work with them on any other outstanding tasks. If there are no more tasks then take the next task from the top of the Sprint Backlog.

    What happens if there is a major incident?

    It is important that any major incidents are dealt with first. Start with any major incidents that occurred in the last 24 hours.

    NewStandUpImage 1710232021942
    Figure: Daily Scrums will alert everyone if there is a major problem and get all brains aligned in the right direction. There is no sense in putting a Band-Aid on a patient's scraped knee if there is a big knife in his eye!

  8. Do you know the 3 commitments in Scrum (Product Goal, Sprint Goal, and Definition of Done)?

    Each step of Scrum is designed to take you towards an outcome, and this is built upon 3 levels of commitment:

    Product Goal

    This is the commitment at the Product Backlog level. It is defined by the Product Owner and ensures continued focus upon progress towards a defined outcome.

    The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

    "A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract."

    The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

    Excerpt from The Scrum Guide

    Tip: Make it easy to find your Product Goal by documenting it in the README of your project.

    Sprint Goal

    This is the commitment at the Sprint Backlog level. It is negotiated between the Product Owner and the Team, and defines the “why” of the Sprint, and how it will help the product eventually reach the Product Goal.

    The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

    The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

    Excerpt from The Scrum Guide

    Definition of Done

    This is the commitment at the Product Backlog Item (PBI) level. This may include testing, deployment, Pull requests, etc, and ensures the quality of each PBI.

    The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.

    The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

    If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

    The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

    Excerpt from The Scrum Guide

  9. Do you know how to be a good Product Owner?

    The client is generally the Product Owner (PO). They should read the Scrum Guide and watch the Product Owner video to understand their role. It is so important to the success of their project:

    Video: What is a 'Product Owner'? - Scrum Guide (2 min)

    What should I do in order to be a good Product Owner?

    1. Be available for Sprint Reviews, Retrospectives and Sprint Planning meetings (approximately half a day for these 3 meetings, for each 2-week Sprint)
    2. Prioritize the Product Backlog. The important things will be done first, in order to maximize the ROI as the budget will run out one day
    3. Be available (at least remotely) to unblock a developer if they have questions/impediments. A good PO has a feeling of urgency
    4. Ideally, listen in on Daily Scrums. This is optional but means that the PO will have daily insight into the team’s progress.
    5. Understand Product Backlog Items (PBIs) and be able to explain what they want using Acceptance Criteria. This is the main way that developers and POs sync their understanding of what needs to be done.

    Note: It is helpful for developers to distinguish acceptance criteria between what is considered "essential" and what is merely "nice to have," as this can prevent them from investing excessive time in meeting non-essential criteria.

    1. Set a Product Goal (the "why" of the Product)
    2. Agree on a Sprint Goal for each Sprint (the "why" of each Sprint)
    3. Not influence (or anchor) developer estimates with comments like “this one will be easy” and allow the team to come up with converged estimates
    4. Respect the Sprint Goal by understanding the team will only work on things in the Sprint Backlog. Don’t expect other things to be done on top of it. Most things can wait for the next Sprint

    Who should be the Product Owner?

    It’s hard to give guidance on who in the company would make a good PO. The usual candidate is often extremely busy. It should be someone:

    1. With a personal stake in the success of the project
    2. Who is available
    3. With a clear vision of the product
    4. Who has authority with the budget. E.g. they could authorize adding a designer to a Sprint for a couple of days
    5. Who has read the Scrum Guide, watched the Product Owner video, and understands the role

    It’s possible to outsource the role of PO to someone in the development consulting company, but this is not recommended ("don’t put the fox in charge of the chickens").

    “Most dysfunction I see in Scrum teams is caused by a bad Product Owner” Adam Cogan - Professional Scrum Trainer,, during a TechEd session

  10. Backlog - Do you always work in priority order, unless there’s a good reason not to?

    Although the team will always strive to complete all the items on the Sprint Backlog within the Sprint, it’s not uncommon for them to not finish all of them. If this is the case, you want to at least make sure that the PO's (Product Owner)’s most important items are done.

    Whenever you are choosing your next task, always work from the top down, only skipping items if there is a dependency or another good reason why a lower item needs to be done first.

    priority order
    Figure: a good example of a team working in priority order. Mid-way through the Sprint, the top items have been completed, the middle items are being worked on, and the bottom items have yet to be looked at

  11. Backlog - Do you know how to create a Sprint Backlog?

    Prior to your meeting with the customer you should prepare. Get your Sprint Planning (was Release Plan) email ready, so after the meeting you can adjust and promptly send it.

    Learn how to create your Sprint backlog:

    Once the backlog is ready, you should send the Sprint Forecast email to the client.

  12. Backlog - Does your Product Owner know how to maintain the backlog?

    All good Scrum teams have a backlog. The backlog is built by taking a conversation and recording it as one or more Product Backlog Items (PBIs) (e.g. Azure DevOps) or Issues (e.g. GitHub, JIRA).

    You should create PBIs during or straight after the conversation, rather than using emails that may never be entered into the backlog.

    Figure: Get typing during a conversation to make the meeting tangible

    The Product Owner is responsible for owning the Product Backlog. See the video on "Do you know how to be a good Product Owner?"

    Although these requirements come from the Product Owner, it is often the developers who will record these PBIs.

    1. Emails

    Figure: Bad example - This is a poor way to add a PBI/Issue as you can’t order emails by the business priority

    Figure: Good example - Github Issues

    3. Azure DevOps - E.g.

    AzureDevOpsBacklog 1710232021931
    Figure: Good example - Azure DevOps allows you to enter an item into the backlog, in any priority order

    What's next?

  13. Backlog - Do you keep your PBIs smaller than 2 days' effort?

    Very often you can come to the end of the Sprint and have incomplete features that either can’t be shipped or can be shipped but don't add any value to the end user or Product Owner. If you are given a feature that is going to take weeks, then split it following this rule.

    Your project could be a very small project spanning just a few weeks/few Sprints or it could be a big project spread across months with multiple Sprint reviews and multiple teams involved. The massive PBI problem finds its way in all projects. Inspite of all devs being available to work, no blockers, no last minute issues hijacking the Sprint, you could still end up either not pushing things to production or pushing some half done feature that can't be used.

    How to avoid this

    There are a few steps to take that help avoid this problem:

    1. Check the PBI is well-defined
    2. Review the PBI estimate
    3. Check if you need a spike
    4. Check the PBI fits in with the Sprint Goal.
    5. Avoid monolithic Product Backlog Items (PBIs). If the estimate is 2 days or more, it can probably be broken down further to make it more manageable.
    6. Consider turning it into a parent PBI with many child PBIs using Epics (Azure DevOps) or Tasks/Sub-tasks (GitHub)

    How to break up PBIs

    When you break a monolithic PBI down, try to see if you can break this into shippable features that the customer can use. From a user perspective, it might be better to have a new UI page with only 2 textboxes that actually save data to the DB than have a page with all UI elements but the save button doesn’t work.

    If shippable features isn't going to work then another good way of splitting up a PBI is to think about what little pieces of functionality can be demoed to the Product Owner in the Sprint Review

    Let's take a look at some examples:

    Say you are doing the Sprint Planning and you see a PBI that says “Sync data with Xero” but not much else. It's been estimated as an 8 day task, which will almost certainly take multiple Sprints. Here are some ways to approach it:

    Example 1 - Sync Data with Xero - UI First

    • Start by having a PBI that shows the sync status of invoices. Then, during the Sprint Review you might not have any backend working, but at least you can show off a nice little UI addition.
    • Next, you might have the logic for syncing the invoice to Xero when you save it. Now in the Sprint Review, you can show that little UI piece changing as it syncs.
    • After that, you might do the reverse, and implement the web hooks to sync from Xero to the app. Then, in the Sprint Review you will be able to show the sync status changing the other way.
    • Finally, the last part might be to implement a manual sync fallback in case the automatic sync fails.

    Example 2 - Sync Data with Xero - Backend First

    • Start by having a PBI that just calls the Xero API with the required data. During the Sprint review, you can then use Postman to demo this API call and Xero getting updated.
    • Similarly, the next PBI could be the web hooks from Xero calling your APIs to send data back which again you can demo via Postman or the Xero developer portal
    • The next PBI can be the API getting triggered via the UI or as required by the app. This part will lend to the demo quite easily.

    If for some reason you do end up with incomplete PBIs at the end of the Sprint, check out Ending a Sprint - Do you know what to do with partially completed PBI?

    Figure: Bad example - This is a monolithic 8-day task

    Figure: Good example - The same monolithic task, broken down into 4 smaller tasks which can all be shipped incrementally

  14. Done - Do you go beyond 'Done' and follow a 'Definition of Done'?

    Having a clear "Definition of Done" for your team is critical to your success and quality management in Scrum.

    The "Definition of Done" is a structured list of items, which exists to ensure that the team agrees about the quality of work they’re producing. It is defined by the team and serves as a checklist that is used to determine completeness.

    Every team is different, but all need to agree on which items are in their "Definition of Done".

    There are 3 levels of 'Done' in communication

    Level 1

    Level 2

    • Documenting/updating the standard (for processes, when necessary)
    • Sending a "Done" email
    • Screenshots
    • Code

    Level 3

    • Documenting/updating the standard (for processes, when necessary)
    • Sending a "Done" email
    • Recording a quick and dirty "Done Video"
    • Code (showing a full scenario, e.g. a user story)

    There are 8 levels of 'Done' in software quality

    Start with these examples showing typical "Definitions of Done" from beginner teams to more mature teams:

    Team - Level 1

    • The code compiles
    • All tasks are updated and closed
    • No high priority defects/bugs are outstanding for that user story

    Team - Level 2

    • All of the above, plus
    • All unit tests passed
    • Tests achieve greater than 1% code coverage (not earth shattering, but you need to start somewhere)

    Team - Level 3

    • All of the above, plus
    • Successful build on the Build Server
    • Git Branch Policies OR
    • Azure DevOps Check-in Policy

      • Change set Comments - all check-ins must have a comment
      • Work Items - all check-ins must be associated with a work item
    • Code reviewed by one other team member (e.g. Checked by Bill)
    • Sending a Done email with screenshots

    Figure: Good example - Add check-in policies to enforce your Definition of Done

    Team - Level 4

    • All of the above, plus
    • All acceptance criteria have been met
    • All acceptance criteria have an associated passing test (e.g. an Azure Test Plans test case or automated end-to-end test in Playwright)
      Tip: Use Microsoft | Azure Test Plans
    • Sending a Done email (with video recording using SnagIt)

    TestPlanning 1
    Figure: Organize tests in suites with built-in E2E traceability across requirements, test artifacts and defects

    Figure: Good example - Done video showing the features worked on

    Team - Level 5

    • All of the above, plus
    • Deployed to UAT (ideally using Continuous Deployment)
    • Complex code is documented (helping to avoid technical debt)
    • Product Owner acceptance

    Team - Level 6

    Team - Level 7

    Team - Level 8 (Gold)

    • All of the above, plus
    • Deployed to Production

    Congratulations! You are frequently deploying to production. This is called “Continuous Delivery” and allows you to gather quick feedback from your end users.

    You might have everything deployed to production, but it might not yet be visible to the end user. This can be achieved by having “Feature toggles” in place. The actual release of the functionality is a decision that the Product Owner and business takes.

  15. Do you have a "Definition of Ready"?

    Just like how the team has a Definition of Done as a checklist for completing a PBI, the Product Owner needs a Definition of Ready to get the PBI in a state that’s ready for it to be added to a Sprint. This should be done as part of the refinement (aka grooming) process and will greatly streamline the Sprint Planning meeting.

    A recommended “Definition of Ready” would be:

    PBI with DOR
    Figure: PBI that meet the DoR

    After the PBI is approved ask for a signature (or simply an initial) as a prove of approval. Check out this rules ask-clients-approval


    1. PBIs can still be accepted into a Sprint even if they do not meet the DoR. When that happens, there will be more risk and uncertainty around the PBI, but this should not stop the team from doing the work. The recommendation is that PBI's are ready, but this is not mandatory.
    2. User Stories should follow the INVEST Principle:
    3. “I” ndependent (of all others)
    4. “N” egotiable (not a specific contract for features)
    5. “V” aluable (or vertical)
    6. “E” stimable (to a good approximation)
    7. “S” mall (so as to fit within an iteration)
    8. “T” estable (in principle, even if there isn’t a test for it yet)

    Following the update to the Scrum Guide for 2020, this is the concept of a Product Backlog being "Ready"

  16. Estimating - Do you break large tasks into smaller tasks?

    A PBI should not take more than 2 days. Each task under it should not have an estimate of more than half a day (4 hours).

    If you have a big task with an estimate of more the 4 hours, you should consider breaking it in sub-tasks. In case the estimate has changed during the Sprint, the “Remaining Hours” field must be updated in order to have an accurate Burndown chart.

    The reason Scrum limits the maximum hours is because you should always know in which task you are working and we believe one single action that takes more than 4 hours might be too generic.

  17. Estimating - Do you know how to size Product Backlog Items (PBIs) effectively?

    A team knows how many PBIs they can commit to by measuring their velocity. The Team estimates the highest priority PBIs in the Product Backlog in Story Points. It is very important for teams to estimate tasks effectively. There are several methods for estimating:

    • Shirt Sizes
    • Fibonacci Extended (1-100)
    • Fibonacci Original (1-21)
    • Doubling
    • Thrown

    Let's go through them:

    Shirt Sizes

    This method is popular with Microsoft teams, but it has the problem of not easily mapping to the common 7 numbers when you enter it into a Task tracking Bug database.

    1 = XS
    2 = S
    4 = M
    8 = L
    16 = XL
    32 = XXL
    64 = XXXL

    Note: In some teams which only use Small, Medium and Large the following numbering is applyed respectively 2, 4 and 8.

    size stories bad example
    Figure: Bad example - Estimation using T-Shirt sizes

    Fibonacci Extended (1-100)

    Planning Poker is a very effective Product Backlog estimation technique and the most common method is using Fibonacci numbers (1,2,3,5,8,13, etc.). This was made popular by Mike Cohn.

    size stories ok example
    Figure: OK example - Estimation using Planning Poker with large numbers

    Fibonacci (1-21)

    Mike Cohn introduced changes to the original 7 cards, by changing the 21 to 20 and adding 40 and 100 to indicate very large user stories called Epics.

    Ken Schwaber (the father of Scrum) says in his Scrum Certification course, that he is not a fan of the extra cards and says he prefers teams keep to the original 7 cards.

    size stories good example
    Figure: OK example - Estimation using Planning Poker with only small numbers

    Estimating using doubling numbers makes relative sizing simple. An 8 point PBI should be about twice the size as a 4-point PBI. This method also simplifies PBI swapping where a PBI is replaced with PBIs totaling the same number of points.

    It has one other advantage over the Fibonacci sequence, it is easier for non-techies because the numbers aren't whacky and the name isn't bizarre.


    Figure: Good example - Doubling simplifies relative sizing


    Another method of estimating is the "Thrown method" as described Martin Fowler.

    This is particularly useful if you don't have Planning Poker cards. Instead of Fibonacci numbers, estimates are from 1 to 5. It's nice and simple, and you only need the fingers on your hand.

    The action is done in the same method as the game 'Rock, Paper, Scissors'. The options the developer can estimate is 1,2,3,4,5.

    fist method
    Figure: PBI estimates using the "Thrown method"

    Other Tips

    #1 Don't Shout Out It will just influence other people's votes.

    #2 Guidelines for Estimating PBIs (aka Anchoring) Every team is different, but you can use the following guidelines for sizing PBIs.

    Estimate ValueExample PBI
    1A less than 2 hours message box change
    4A timeboxed task for 1 day x 1 developer
    8A timeboxed task of 1 day x 2 developers
    64More than a month with a couple of developers (Don't include these in a Sprint because they are too risky. See #4 below)

    Figure: Good example - Example PBI estimates

    #3 Using a Chat Program If you are working on a project with a remote team, use Microsoft Teams chat to size PBIs using Planning Poker. Everyone should give their points for PBIs at the same time to avoid influencing each other.

    #4 Big PBIs Smell PBIs of greater than 2 days are a smell and PBIs greater than 4 days are a stench. If PBIs are estimated at more than 4 days of work, consider splitting them into smaller pieces to keep them under 2-4 days. See Do You Break Large Tasks into Smaller Tasks?

    #5 Use Spikes If you do find a very large PBI, consider using a Spike (aka. an investigation task) to help work out how much work will be involved.

  18. Do you estimate “Business Value”?

    You do Scrum, but do you use the "Business Value" field?

    That's OK, most teams don't... but it is a shame, because developers go to the trouble of estimating 'Effort' and if you have Effort, all you need is Business Value and you can calculate ROI.

    Once you have ROI a Product Owner can use the ROI field to sort priority. Awesome.

    ROI (Return on Investment) is an unbelievably simply calculation.

    business value field
    Figure: Product Owners should be estimating the Business Value

    ROI = Business Value / Effort

    ...of course there are other factors to consider.

    E.g. Risk, Dependencies etc and you could make the formula more complicated....

    Priority = (Positive Value - Negative Value) + Risk + Dependencies / Effort

    ...but don't bother.

    The Product Backlog is just a list of items with rough estimates of both development 'Effort' and 'Business Value'. You will find that ROI will tell you great stuff. It is especially useful for finding the easy high value items to kick off a Sprint.

    Product Owners are too busy for this

    If it is good enough for developers to estimate story points... then it is good enough for the Business to estimate Business Value. Usually devs will use the Fibonacci sequence, but since it is a good idea that the business guys use the same scale, it is best to switch to the doubling method of estimating - Do you know how to size user stories effectively?

    For example, if the "add rich text box" and "add sortable column headings on the grid" have the same business value of 3, the one with the smallest development effort will have higher priority (the ROI is greater).

    In summary, the simple calculated field ROI, can automatically order the backlog tasks for the Product Owner, makes estimating Business Value just good sense.

    PBIs can provide value in several ways:

    • Commercial Value: How does this item increase our revenue or profit?
    • Efficiency Value: How does this save us time or money?
    • Future Value: How will this save us money or time in future?
    • Customer Value: How does this increase the likelihood that a customer continues to use our project?
    • Market Value: How does this allow us to attract more users or customers?

    For more on this see Five Types Of Value |

  19. Do you have a good technical overview?

    When running a project, having someone with a high level view of the project is extremely valuable. That person is much more likely to notice broader problems and be able to act to correct them.

    It is highly effective to have this person attend Sprint Reviews and Planning. Attending Daily Scrums is also valuable but not essential; even attending occasionally has value. They could potentially also act as Scrum Master, but in many organizations they do not.

    This person's objectives should include the following:

    1. Provide feedback to the Product Owner on what’s in the backlog

      • Are items sensibly sized? Will they fit into a Sprint comfortably? Should they be broken down further?
      • Are there risky items in the backlog that could do with a spike to research the risks?
      • Do the items address the goals of the project? (you'd be surprised how often the answer is no to this one)
    2. Provide feedback to the Product Owner on prioritization

      • Often a Product Owner will feel everything is most important; get them to list things in order
      • Review prioritization just before Sprint Planning
      • Try and provide tips on how to think about prioritization (asking questions like "Is A more important than B", "If yes, we should move A above B in the backlog")
    3. Provide feedback to the Scrum Master on how things are running

      • Often the Scrum Master will miss things due to being bogged down
      • Remind the Scrum Master their role is to facilitate and assist in eliminating blockers
    4. Give big picture feedback, highlighting the requirements that often get missed, encouraging the Product Owner to decide which items are most important in their context. The most common of these are:

      • Performance
      • Cost
      • Scale
      • Reliability
      • Availability
      • Disaster Recovery
    5. Provide a sounding board for technical questions
    6. Provide a backup for the Scrum Master if they take leave or any other break
    7. Identify problems. Quite often the distant observer can see impending disaster way before everyone who is stuck in the details
    8. Learn from seeing other teams in action.

      • What works well in the team being observed that might help in another project?
      • Was the response to a problem really effective?
      • What value did I bring?
  20. Do you send "Sprint Forecast" and "Sprint Review/Retro" emails to the client?

    Each Sprint has a "Sprint Forecast" email that details what will be worked on during this Sprint.

    At the end of the Sprint, this should be replied to with a "Sprint Review" email that shows a breakdown of what was completed.

    If you're using GitHub to manage your project, create repeatable templates that can easily edited and emailed out.
    See GitHub Issues - Do you create a template for your Sprint Reviews, Retros and Forecasts? for more details.

    Each Sprint has the following stages:

    1. Planning meeting

    2. Work in progress

      • "Done" emails are sent asking for specific functionality to be tested
      • See Rules to better Email for details
    3. Review and Retro meetings

  21. Do you record a summary of Sprint Reviews for the stakeholders?

    Creating a comprehensive summary and recording of Sprint Reviews is a great way to communicate changes in a Product to the community and stakeholders. Especially for people who are unable to attend these meetings.

    Why Create a Summary and Recording?

    1. Enhanced Clarity and Transparency: Provides a clear, accessible update for all stakeholders, including those not present.
    2. Documentation for Future Reference: Serves as a historical record of decisions and discussions, valuable for future sprints and project continuity.
    3. Inclusive Stakeholder Engagement: Ensures that all stakeholders, regardless of their availability to attend, have access to the same information, promoting inclusiveness and alignment.
    4. Community Engagement: Allows the community at large to see what is happening on a product and provide feedback.

    Best Practices for Effective Summaries and Recordings

    Preparing the Summary

    • Highlight Key Points: Focus on decisions made, goals achieved, and major discussions.
    • Use Clear, Concise Language: Ensure that the summary is easily understandable, avoiding technical jargon where possible.
    • Include Actionable Items: Clearly note any action items or decisions that require follow-up.
    • Keep it Generic: Viewers might not have the same context of the Product, so try to present PBIs as though the viewers do not have prior knowledge.


    Here's a suggested runsheet for what to cover in the video:

    1. Show the Product website
    2. Run through Sprint Review Email
    3. Run through Sprint Planning Email
    4. Finish on the Product YouTube Channel

    Making the Recording

    • Ensure Good Audio Quality: Use a decent microphone and test audio levels before starting.
    • Capture Visuals: Record the screen or presentation to provide context to the discussions.
    • Keep it Engaging: Even though it’s a recording, try to keep the delivery lively and engaging to maintain viewer interest.

    Utilizing Modern Tools for Recording and Editing

    Using Microsoft Teams Record Feature

    • Start Recording: Utilize the built-in recording feature in Microsoft Teams to capture both audio and video of the Sprint Review.
    • Notify Participants: Always inform participants that the session is being recorded, ensuring compliance with privacy policies.

    Editing with ClipChamp

    • Import the Recording: Once the meeting is over, download the recording and import it into ClipChamp.
    • Edit for Clarity: Trim unnecessary parts, highlight key moments, and add titles or transitions to enhance viewer understanding.
    • Use a consistent professional thumbnail: Get the design team to make you a nice thumbnail to use for your Sprint Reviews so that it looks professional.
    • Export and Share: Once edited, export the final video and consider uploading it to a platform like YouTube for easy access and sharing within your organization.

    Examples of Good vs. Bad Practices

    "Simply jotting down a few notes or making a low-quality audio recording on a phone."

    Figure: Bad example - Inadequate details and poor audio quality can lead to misunderstandings and disengagement

    "Preparing a structured document that highlights all key outcomes, decisions, and next steps, accompanied by a high-quality video recording of the session."

    Figure: Good example - Provides a comprehensive and clear record that is useful for all stakeholders

    By adopting these practices, teams can ensure that the outcomes of Sprint Reviews are effectively communicated and documented, supporting project success and stakeholder satisfaction.

  22. Do you create a Sprint Forecast? (aka The functionality that will be developed during the Sprint)

    After the Sprint Planning meeting, it is useful for the Development Team to send the Product Owner (PO) a Sprint Forecast for the next Sprint. Doing this helps to improve common understanding in, and sometimes to enforce, the relationship between the PO and the Team.

    This is simply an agreement between the Development Team and the PO for one Sprint and should be confirmed via an email at the beginning of every Sprint.

    “The implementation team agrees to do its best to deliver an agreed on set of features (scope) to a defined quality standard by the end of the Sprint. (Ideally they deliver what they promised, or even a bit more). The Product Owner agrees not to change his instructions before the end of the Sprint.”
    Agile Project management

    Each Sprint in a Scrum project can be considered a mini-project that has time (Sprint Length), scope (Sprint Backlog), quality (Definition of Done) and cost (Team Size * Sprint Length). Only the scope can vary and this is measured every Sprint.

    Figure: Good example - Copy this as email template and send to Product Owner

    ::: infoTip: You can copy and paste the Sprint Backlog as a table into the email body:

    1. Go to Azure DevOps and navigate to the Sprint's Backlog view
    2. Remove the unnecessary columns so it looks clean
    3. Select all items, copy, then paste into the Sprint Forecast email :::
  23. Do you create a Sprint Review/Retro email?

    After any Sprint Review and Retrospective, an email should be sent to all the stakeholders to update them on the outcome from the Sprint:

    Firstly, create a new email copying the information from the previous Sprint Review/Retro. As per Do you know what happens at a Sprint Retrospective meeting?, it should include the following:

    It's important that an Email Group is setup for the project, and the Sprint Review is sent to that group, so that anyone who joins the project in future can access these reports from shared inbox as per Do you choose which Microsoft 365 Groups you follow?

    Figure: Good example - Template for Sprint Review/Retro email

    tina sprint email
    Figure: Good Example - TinaCloud team Sprint Review email

  24. Meeting - Do you update your tasks before the Daily Scrum?

    All team members must update their tasks with status, (and remaining hours if you are estimating tasks) prior to the daily Scrum meeting.

    screen shot 2021 10 29 at 8 06 46 pm
    Figure: Update your tasks to keep the burn-down rate accurate

    Note: If you are updating the details of a PBI then follow the rule Do you know when you use @ mentions in a PBI?

    In Scrum, there are 4 meetings in total that you need to know about:

    Scrum at Microsoft Videos

    Short Version (3:48)

    Long Version (12:15)

  25. Scrum Meetings - Do you know what to prepare for each meeting?

    In Scrum, meetings are time boxed. Team members should be well prepared in order to accomplish the meeting goals in time.

    Daily Scrum Meetings

    This is time boxed to 15 mins. All members of the team should be well prepared by:

    • Being ready on time
    • (If your team is estimating tasks) Having their "Remaining hours" up-to-date – read Do you update your tasks before the daily Scrum meeting?
    • Be ready to answer the 3 main questions: - What did you do yesterday? e.g. "Yesterday I did xxx" - What are you doing today? e.g. "Today I will do yyy" - Do you foresee any impediments or roadblocks? e.g. "I might hit a roadblock today because of xxx"
    • Remember to say "Let's park that conversation for after the Daily Scrum". Major discussions are not to be conducted during the time boxed Scrum meeting.
    • Being online on Skype (especially for team members in different locations).

    Sprint Review Meetings

    All members of the team must be well prepared by:

    • Deploying the latest iteration of the product
    • Being available 30 minutes before the meeting
    • Setting up and testing the projector with a computer before the meeting starts
    • Making sure remote members are connected via Skype and/or TeamViewer before the meeting starts
    • Nominating in advance another member of the team to take notes from the presentation
    • Deciding, in advance, the order in which PBIs should be presented; priority, Sprint backlog order, logical order and minimizing presenter and presentation medium switching should be taken into account.
    • Controlling the time spent on the PBI presentation

      • Practice the demo beforehand if needed to ensure a succinct delivery. This can be in the form of a pre-prepared video if desired
      • Inform the Product Owner what the main goal of the PBI is and tell if the team believe it was done or not
      • If the Product Owner previously saw what was done, ideally the member should just mention that and ask if the PBI is accepted
      • If the member needs to show something, show a couple of examples and ask if the Product Owner wants to see something else

    Sprint Retrospective Meetings

    All members of the team must be well prepared by:

    • Having all your tasks from the last Sprint closed
    • Having your Sprint feedback ready in advance, so members don’t need to think about it during the meeting, saving time
    • Being clear and pointing out issues that need further discussions

    Sprint Planning Meetings

    All members of the team must be well prepared by:

    • Having all bugs and PBIs up-to-date on the backlog
    • Having all PBIs on the backlog “groomed” in order of priority (according to the Product Owner)
    • Understanding all PBIs and the Product Owner’s priorities
    • Being responsible on estimates
    • Volunteering to work on PBIs and tasks, even if they are not related to your best skills – read Do you encourage multi-skilled teams?
  26. Calendar - Do you use a centralized Daily Scrum calendar?

    You should have a centralized calendar to easily find all your company's Daily Scrum meetings.

    The easiest way to do this is to use a shared calendar that is just used for Daily Scrums. At SSW, we have the SSWDailyScrum calendar for this. This requires each team to send their Daily Scrum as a recurring appointment to the SSWDailyScrum calendar.

    This calendar helps mapping all the SSWDailyScrum appointments, by keeping them all together, and anyone who wants to know about any team's Daily Scrum can use this calendar to find out when it is.

  27. Tasks - Do you know that every PBI should have an owner?

    When you are building complicated software and working with customers it is always nice for them to have some idea on who to speak to about a particular PBI during a Sprint. In order to achieve this one of the Team takes responsibility for “looking after” a PBI.

    They will collect all of the "Done emails and make sure that everyone follows the Done criteria identified by the team as well as answering any Product Owner queries.

    PBI Owner Reposibilities

    The role of the PBI Owner is like a mini project manager. The PBI Owner resolves any road blocks, performs the “Test Please” and makes sure there is a good presentation at the Review Meeting. In addition, having a PBI Owner makes it easy for Product Owners and others to talk to the right person when they need to.

    There are five main things that the PBI Owner is responsible for:

    • Manage / Own the story and its sub tasks
    • Make sure a “Test Please” is conducted (or that their story is included in one)
    • Make every effort to show the story to the Product Owner before the Sprint Review (aka a corridor conversation)
    • Prepare for the Sprint Review. Make sure he ready for the review. Have a scribe, have a demo plan/script and get the story accepted quickly
    • Present the completed PBI at the Sprint Review

    During a Sprint it is useful for:

    • The Product Owner to know who to speak to regarding a PBI
    • The Team to know who will be presenting the PBI at the Sprint Review

    Note: Beware this is intended for convenience and should not conflict with the following Scrum principals from page 6 of the Scrum Guide.

    • The Development team is self-organizing
    • Accountability belongs to the development team as a whole

    UserStoryOwner Bad
    Figure: Bad example - The Product Owner is not sure who to speak to

    UserStoryOwner Good
    Figure: Good example - The Product Owner can now see who he should speak to and developers know where to send done emails

    screen shot 2021 11 02 at 9 20 07 am
    Figure: Assignees in GitHub

  28. Tasks - Do you know to use clear task descriptions?

    When you create tasks in Scrum you are doing this within a time box and you tend to add only the information you need to remember what the task is. And the entire Team was at the meeting and were involved in the discussions around the task, so why do you need more?

    Once you have accepted a task you should then add as much information as possible so that anyone can work on that task.

    You can use rich text and images to be extra clear, or even attach an email to the task.

    screen shot 2021 11 02 at 9 30 39 am
    Figure: Bad example - there is not enough information for anyone to complete this task

    screen shot 2021 11 02 at 9 30 14 am
    Figure: Good example - Azure DevOps - Lots of information so anyone can pick up that task

    screen shot 2021 11 02 at 9 54 20 am
    Figure: Good example - GitHub - Lots of information so anyone can pick up that task

    Note: If you are updating the details of a PBI then follow the rule on using @ mentions.

  29. Do you understand the implied contract (promises) between Members of the Scrum Team?

    Working together as a team is hard. Especially with the distractions that are around as part of daily office life. You need all three partied to a Scrum team, the Product Owner, the Scrum Master, and the team, to work together to achieve the Sprint Goal.

    From Scrum Alliance:

    "Scrum defines three distinct roles that must work together as a Scrum team to produce a successful product. The Product Owner is responsible for understanding what stakeholders require, interpreting these requirements for the team, and providing clear prioritized direction. The team is composed of those people actively engaged in building the product. The team collectively and members individually are responsible for building the product according to the priorities and requirements provided by the Product Owner. The team is completely responsible for deciding how to achieve its goals and how to organize its work. Finally, the Scrum Master is responsible for the health of the process, reporting the progress of the team, and removing impediments to progress."

    With these roles come a number of promises between the 3 parties, the Product Owner, the Scrum Master, and the team. These promises should be formalized so that everyone knows where they stand.

    The Organization- the team that there are stakeholders (including subject matter experts) who will help when needed
    - they will help the Scrum Master in the removal of impediments to the Scrum team’s progress
    - the team that they will not change priorities or constraints in the middle of a Sprint without team’s consent
    - that being on a Scrum team will not hurt the members’ careers
    - not to divert team members to other work on a Scrum Day during a Sprint
    Product Owner- to supply an initial Product Backlog
    - to prioritize the Product Backlog when needed
    - to be responsive to requests for feedback and clarification
    - empowered “voice of the customer” will be provided to answer business domain questions promptly (minutes or hours, not days)
    - to attend every Review, Retrospective
    - not to change priorities or scope during a Sprint
    - not to direct team members to do work not agreed and planned at the beginning of the Sprint
    Scrum Master- to keep the team healthy by focusing on the removal of impediments, both internal and external
    - to protect the team from external distractions
    The Team- that its work will be transparent, that it will make decisions and solve problems as a group, and that no individual team member will be left behind
    - to take prioritization and scope from the Product Owner on the team driving the team based on stakeholders interests
    - to use the stakeholders’ time wisely, by focusing on questions that are relevant to the work being done now
    - to do quality work the best way they know how within the constraints set forth by the organization
    - to deliver demonstrable product at the end of every Sprint for reviewing and validation by the stakeholders
    - to endeavor to become multi-skilled by sharing and pairing and not relying on experts on the team for specific functions
    Team Member- to bring issues, problems, impediments and realities encountered to the team
    - to be available and working with the team on every defined Scrum Day of a Sprint in which they committed and any required absences will be scheduled before the beginning of the Sprint
    - to attend every Scrum, Review, Retrospective & Planning Meeting
    - to refer any external request that will take more than 15 minutes of Scrum Day time to the Scrum Master
  30. Do you make sure Sprint Reviews are "tick and flick"?

    It's essential to keep Sprint Reviews as efficient as possible. Unfortunately, Sprint Reviews can be boring because they involve developers slowly demoing each Product Backlog Item (PBI) to the Product Owner. Better communication with the Product Owner can transform this into a swift "tick and flick experience", leading to more efficient reviews.

    Get your PBIs into a "tick and flick state"

    Getting a PBI into a "tick and flick state" involves ensuring that the Product Owner has been shown the PBI, reviewed the changes and provided feedback. It can be a physical demo, or it can be a Done Video.

    If the developer has shown the Product Owner the PBI prior to the Sprint Review, then in the Sprint Review, when the PBI is reached the developer can remind the Product Owner it's been reviewed and ask if they are happy to move on.

    Developer: This PBI is about making the new customer contact form. Let me show you what I've done:

    🖥️ Developer Demos the change

    Developer: Any questions?

    Figure: OK example - Showing the Product Owner the PBI for the first time during the Sprint Review

    Developer: This is the PBI I showed you on Monday about creating the new customer contact form. Are you happy to move onto the next one?

    Figure: Good example - Confirming that the PBI has already been reviewed so you can move on

    How do you make a Sprint Review a "tick and flick experience"?

    To make a Sprint Review a "tick and flick experience" you want as many PBIs as possible to be in a "tick and flick state". Every project is different, so the process will differ depending on the project and the Product Owner's preferences. However, the general idea is that you communicate the completion of a PBI to the Product Owner and give them a visual indication of what was changed.

    Here are some tips that help improve communication with the Product Owner during a Sprint to help get the PBI into a "tick and flick state" and ready for the Sprint Review:

    1. Use @mentions in a PBI - Utilize @ mentions in a PBI to alert the Product Owner and other relevant team members about any updates, questions, or issues related to a PBI. Using @mentions ensures that everyone stays informed, and any concerns are addressed before the Sprint Review
    2. Document Decisions and Discoveries - While working on the PBI make comments about any decisions or discoveries, that way when a Product Owner reviews the PBI they will be able to see the context of everything that happened
    3. Close the PBI with context - By adding relevant information to close off the PBI, the Product Owner can quickly get a handle on the status of the PBI
    4. Send 'Done' emails - Use 'Done' emails to notify the Product Owner when a PBI has been completed. This includes a brief description of the work done, links to relevant documentation, and any other essential information. Sending these emails helps keep the Product Owner informed and allows them to prepare for the Sprint Review
    5. Send 'Done Videos' - When appropriate, make a habit of including a short video demonstrating the completion of a PBI in your done email. This will give the Product Owner an opportunity to review the work before the Sprint Review meeting, saving time and ensuring any issues are addressed beforehand
    6. Call the Product Owner to run through what's been done in the PBI

    By incorporating these tips into your team's workflow, and turning PBIs into a "tick and flick state" you can keep the Product Owner informed and subsequently make Sprint Reviews a "tick and flick experience".

  31. Done - Do you know to send a 'done' email in Scrum?

    Some Product Owners aren’t always abreast of your team’s Sprint board!

    Follow the 3 steps to completing a PBI and when you’re done, close the PBI with the word ‘Done’.

    A good approach is:

    • If a task/bug came from a client when it is completed, send the 'Done' email to the Product Owner
    • If the task/bug is your breakdown of a PBI (that the developer did to break down a big User Story), then only send the ‘Done’ once the entire User Story is complete

    GitHub Note: If you are using GitHub, you can close the issue with a comment, and @mention the people you wish to notify - GitHub will then email them for you, assuming they have configured it correctly. This has the bonus of being visible to everyone else who can see the issue, without needing to Cc everyone on your emails.

    When replying ‘Done’ to a PBI

    When sending a done email, you want to encourage them to refer back to your PBI.

    1. Follow the 'Done' email rules
    2. Include a link to the PBI with a copy of the important details
    3. Remember that all your tasks should be under 4 hours
    4. If you completed the PBI in a different way than previously discussed, ensure that it is referenced in the PBI as per the Document Discoveries rule
    5. Make sure that your PBI has an Owner
    6. Link to your team’s Definition of Done and show that it has been met
    7. ⭐️ Remember to escalate your email to the appropriate stakeholders when needed

    You can go the extra mile and inform Product Owners and Stakeholders with key updates. This is especially useful when the Product Owner is not checking Azure DevOps or GitHub.

  32. Done - Do you know when to do a “Test Please” in Scrum?

    Something you must do is to conduct an internal ”Test Please” prior to releasing anything to a client. This should be done by someone outside the Scrum Team and as it is a blocking process must be started within an hour and take no longer than 3 hours to complete.

    In Scrum, you should conduct a separate “Test Please” for each of the stories. You might be using the same package, but all the bugs and issues found must be rolled up to the Story Owner as they will need to decide on what needs to be done to deliver their User Story.

  33. Done - Do you know how to make sure you deliver a build that’s tested every Sprint

    What happens when you leave all the testing to the end of the Sprint? You find things that are not done and you have no time before the Sprint Review to fix them.


    Figure: Bad example - if you don’t complete all the tasks the customer will not receive a build in the Sprint

    One way to mitigate this is to aim for a “ test please ” to occur a few days before the end of the Sprint but you still run the risk of not having enough time to make sure everything is done.


    Figure: OK example – Send the “test please” before the end of the Sprint so you have time to finish everything

    It is preferable to conduct a Smoke Test to make sure that you are comfortable demoing the unit of work you just finished to the customer. One way to do this is to create a Coded UI test for each of the Stories as part of your Definition of Done (DoD) that runs through the functionality you have built.

    In this scenario the “ test please ” with the customer happens outside of the current Sprint.


    Figure: Good example – Create a coded UI test for each story to prove that it is complete

    If you are doing Scrum then you should have a User Story fleshed out with a set of Acceptance Criteria . These Acceptance Criteria are agreed with the Product Owner before The Team committed to the story, and define what the Product Owner will accept as complete. This makes it relatively easy to create some automated tests that test for these Acceptance Criteria and help your Sprint Review go as smoothly as possible.

    Any changes found during the Sprint Review get added to the Product Backlog to be prioritised by the Product Owner .

    RuleBuildEverySprintUltimate Figure: Ultimate example – Create a Test (could be Coded UI) for each of the Acceptance Criteria agreed with the Product Owner

  34. Do you know how to handle Undone Work (aka V2 for PBIs)?

    The goal is always to complete Product Backlog Items (PBIs) for the Sprint Review.

    Often PBIs grow or change and it does not make sense to deliver what was originally proposed in the Acceptance Criteria.

    So think of a way to deliver business value and get it in production, then have a hallway conversation with the Product Owner to see if he agrees with you.

    Assuming approval, then adjust some of the Acceptance Criteria, add "v1" to the PBI name and move some of the functionality to a new PBI with the same title and "v2".


    • Customer and Contact Form v1
    • Customer and Contact Form v2

    Note: A common example for when to use this is when the full acceptance criteria of a large PBI (or Epic) would not be attainable within one Sprint, so splitting an Epic into 2 attainable PBIs is a better option.

    2021 07 30 14 58 22
    Figure: A v2 PBI in GitHub

    2021 07 30 14 59 25
    Figure: A v2 PBI in Azure DevOps

  35. Ending a Sprint - Do you know when to remove PBIs from the Sprint?

    There are two reasons that a PBI can be removed from the Sprint.

    1. Your team notices that they can’t get everything done, and agree with the Product Owner to remove the PBI.
    2. At the Sprint Review meeting the Product Owner rejects the story

    There are a few reasons a team can find themselves in a position where they can't get everything done.

    1. They underestimated one or more PBIs
    2. PBIs were blocked by other PBIs

    In all cases, when a PBI is removed from the backlog, it moves back to the top of the backlog and any unfinished tasks left in the Sprint are closed.  When the Product Owner next grooms the backlog, or during the next Planning Meeting, he may decide to prioritise the PBI high enough to make the next Sprint, but he may not.

  36. Ending a Sprint - Do you know what to do with partially completed PBI?

    At the end of a Sprint, if a PBI has not been completed and therefore cannot be marked as done:

    1. Update the Effort to be just what is remaining
    2. If there has been scope creep, but the original Acceptance Criteria has been met, it might be a good opportunity to mark it as done and move any scope creep tasks into a V2 of the PBI, which can then be prioritised in the backlog by the Product Owner
  37. Ending a Sprint - Do you know what to do when your Sprint fails?

    Having a rejected Sprint is so rare that you should be hard pushed to find any team that has had one.

    If you do then this highlights an underlying communication issue and most likely a lack of participation by the Product Owner.

    See Do you have a contract between the Product Owner and the team?

    If however you do get a failed Sprint and the Product Owner is not willing to accept the code that has been written then you need to rollback your source code and put all the stories back onto the Product Backlog.

  38. Do you know that working in a team is better than on your own? (aka The Ben Darwin rule)

    Is working as a team all it is cracked up to be?

    It's a well known fact that a good team of 3 people will output more than 3 people working on their own. As well as that, the team members will find it more rewarding as well.

    The best sum up of this was by famous Wallaby player, Ben Darwin, who after breaking his neck in a Scrum. He was forced to quit being a Wallaby and rejoin normal society. He said:

    I found the hardest issue of all was that I missed my friends, basically, and that's what I told them when I gave them the jersey for the final. I just missed the 14 guys. There's a feeling that comes in sport, particularly in team sport, where we say we feel jealous of the wages of individual sportspeople but never jealous of the lack of team. When you finish a game of football and you've played together and you walk off with the other 14 men, the guys on the bench, and you've overcome an opposition, you don't have to say anything to each other. You can simply look your fellow man or other player in the eye, and he knows you helped him, and you know how he helped you. That's enormously satisfying, and I haven't found that anywhere else in life.

    We can see examples of this in nature as well. For the Antarctic Emperor Penguin, cooperation is the key to survival. Every winter thousands of male penguins huddle together to share warmth. The birds on the most exposed side of the huddle gradually move down around the huddle to the more sheltered side. This means that each bird spends some time exposed to the full force of the Antarctic winter, but then gets its fair share of warmth in the middle of the pack. These clever birds understand that by taking turns and enduring discomfort in the short term, their chances of success (survival) greatly increase.

    It is essential that in order to be a contributing member of a successful team, you are willing to put the good of the team over your own interests so that everyone can benefit in the long term.

    Video: Emperor penguins unite for survival in Antarctica - David Attenborough - BBC wildlife (2 min)

    Note: If this beautiful story is not up your alley you will prefer a similar example of working as a team by the IT Crowd (Unavailable outside Australia).

    Tip: Leverage existing organizational experience and learn from the best. Does your company have a ‘super star’ team? If so, why not ask to sit in on one of their meetings, or take a few of their team members to lunch and ask them for advice on increasing your own team’s performance.

    Suggested questions to ask the experts:

    • What do you define as success?
    • What are the things that you do not worry about?
    • What practices do you believe lead to your success as a high performing team?
    • Do you have defined/document practices and procedures that you follow?
    • What tools do you use that contribute to your effectiveness?
    • What metrics do you use to measure your success?

    With the rest of your team, prioritize the feedback you received and select a few key items that you can implement right away. Make a backlog from the feedback you received, set some goals and start your team on the road to being ‘Superstars’ too.

  39. Do you know how to handle unexpected requests in the middle of a Sprint?

    To use Scrum correctly, all team members must understand the importance of Sprints, Sprint Planning, and capacity. Sprints are sacred - they give the team a clear goal, with a clear set of tasks and a timeframe to achieve it in.

    However, Product Owners or stakeholders can derail a Sprint by coming to the team with a new task that wasn't planned for. Maybe it's a new feature, or a critical bug, or just a time-sensitive item that appeared out of the blue.

    These interruptions may occur frequently - especially with clients or teams that aren't familiar with Scrum. Therefore it's important to teach the client how to treat the team.

    Video: The best way to handle requests from your boss (2 min 38 sec)

    If a Product Owner or stakeholder comes to you with a new request, it's important that you first acknowledge it (e.g. "That's a great idea!"). Then, you need to establish the priority.

    If it is a stakeholder who contacted you, loop in the Product Owner so they can help prioritize. If you can't reach the Product Owner, let the stakeholder know you will ask the Product Owner about it later.

    If it is the Product Owner who contacted you, then you need to work with them to figure out the priority. Most of the time, the Product Owner is happy to add the new request to the product's backlog. But every now and then, they are going to want to change your priorities and have you work on something which they see as more important than some of the items in your current Sprint.

    So what will you do when this happens?

    Generally, it's good to stick to the "customer is always right" philosophy. However, there are a few things you should do to protect the integrity of the Sprint.

    1. Double check with the Product Owner that this new item is more important than the current Sprint items (if not add it to the Product Backlog instead)
    2. Add the new PBI to the current Sprint
    3. Remove another item of similar size from the Sprint and put it back in the backlog

    Figure: Good example - For urgent changes, you can substitute in some PBIs as long as you stay within capacity

    Sprint Goal RIP?

    In the rare case where the entire Sprint goal and all PBIs are no longer high priority, you can instead cancel the entire Sprint and start again:

    1. Move any left over work/items to the backlog
    2. Send a debrief to the client with a note. E.g. As per your request we have just cancelled Sprint 05 and will start on Sprint 06. The remaining items have been moved into the backlog.
    3. Send a Sprint Forecast for the new Sprint

    This should only be done in extreme circumstances as it is traumatic to the team.

  40. Do you always know what are you working on?

    Team members should always know in what task they are working on and make sure Azure DevOps (was TFS) is up-to-date.

    It’s natural that everyone spends some time on grooming, making decisions etc, so it’s not expected that all team members work 8 hours per day on tasks. However, ideally everyone should be doing as many hours as possible.

    If they are doing something for the team that is not a team meeting or for a task assigned to them that will take more than 30 minutes, they should create a new task with an accurate original and remaining estimates. When helping somebody else with a task, the team member should create a new subtask to that task to cover their help.

    To always know the task you are working on is very important for the Burndown accuracy and also make it easy to check what work has been done and what are the impediments.

  41. Product Owners - Do you know the consequence of disrupting a team?

    Disrupting a team member can affect the delivery of the whole Sprint. Product Owners should always avoid giving tasks outside the Sprint. It may seem to affect just one member, but it does affect the entire project.

    With Scrum, the team commits to deliver some set of functionality by the end of each Sprint and the whole team is accountable for what they engaged to deliver. Missing a team member, even if temporarily can affect the success of the Sprint, the Scrum Master may recommend removing stories to be delivered. Product Owners must be aware of how Scrum works and understand the importance of keeping the team focused on their tasks.

    Team members need to be completely transparent with the Product Owner, the Scrum Master, and the rest of the team. Even if someone offers them a free trip to Iceland, they still need to ask permission from the Product Owner as it can affect the Sprint.

  42. Communication - Do you send "Done Videos"?

    The big communication points with clients are:

    • Daily Scrums (Product Owners often don’t join)
    • Sprint Review, Retro and Planning
    • Done Videos

    Most Scrum teams do the first 2 well but Done Videos are less common.

    A picture is worth a thousand words; and a video is worth a thousand pictures.

    Clients love Done Videos. Done Videos offer transparency, visibility, testing, and early releasing of a feature they might otherwise have to wait weeks or months to see released. The video lets them see the new feature and enables early feedback, which is beneficial to both the developer and the client.

    The best way to demonstrate that a new piece of functionality is working is to record yourself using it successfully. this works as both a demo, as well as a training aid if they need to reference it again later.

    The benefits of Done Videos are:

    • Product Owner - The PO (often the client) can watch as many times as they like
    • New Developer - Shows what the feature does
    • Developer - They can be referenced in code for others in the future
    • UX designer (and tester) - Easy to can give feedback
    • User - can be included as documentation

    Figure: Video call with the client

    How to do a Done Video

    Do you know how to record a quick and dirty 'Done Video'?

  43. Do you know how to record a quick and dirty 'Done Video'?

    When you've finished a PBI you should record a video to send to your Product Owner and anyone else that is interested. A 'Done' video is much better than a screenshot because you are proving the PBI workflow actually works. Even better, this video can double as documentation or release notes for your users.

    When deciding whether a PBI might be a good contender to record a Done Video for, consider these factors:

    1. Is it a key piece of functionality that has high business value?
    2. Would it be difficult to quickly demo in the Sprint Review without a video?
    3. Is it UI heavy? i.e. Would the video be compelling?

    Choosing software to record your screen and camera together: Check out SSW Rule Do you know how to record your screen? for the best options.

    Choosing software to edit your video:

    • Basic editing: Video Editor (for Windows), iMovie (for Mac)
    • Advanced editing: Adobe Premiere Pro, Final Cut, DaVinci Resolve

    For a Quick and Dirty Done Video

    Here's a video describing how to record and edit a quick Done video using Clipchamp:

    Tip: Jump to 04:31 for how to record screen and webcam.

    Video: BEST Clipchamp Video Editing Tips and Tricks (14 min)

    Here's a video describing how to record a quick Done video using OBS:

    Video: How to Record your Computer Screen & Webcam in OBS Studio (8 min)

    Note: The PIP will be baked in and cannot be altered later.

    For a more professional video that requires some editing

    Here's a quick video describing how to record your webcam and screen separately in high-resolution using OBS for post-processing and editing:

    Video: How to Record Webcam and Game Separately in OBS Studio | Tutorial (10 min)

    Note: You will be able to alter the PIP, remove it, go full screen on your face... whatever.

    Switching Scenes in OBS - it is quite easy to do with these simple steps using OBS Hotkeys!

    Video: How To Switch Scenes In OBS Easily! (OBS Hotkeys) | Tutorial (4 min)

    Here's a quick video describing how to record and edit a quick Done video using Camtasia.

    Video: Make a Quick and Dirty "Done" video in Camtasia (2 min)

    Camtasia Tips

    Tip #1: Camtasia - See great example by Ben Cull

    E.g. A real example of a 'Done Video' with fades:

    Video: SSW TimePRO - Power BI Ad-Hoc Reporting (4 min)

    Tip #2: Camtasia - Fix the audio before making any cuts to the video

    After recording your video, you need to do some basic sound processing to make the audio awesome.

    • In the Timeline, select the clip with the audio
    • On the top left panel, click ‘Audio Effects’ and drag the ‘Levelling’ effect onto your clip
    • On the timeline, move the new audio meter up just until the audio waveform is about to hit the top
    • Listen and adjust as necessary

      audio effects panel
      Figure: Camtasia - audio effects panel with the compressor

    Tip #3: Camtasia - Fade-out and fade-in the video track of your face

    1. With the video track of your face selected, click on Animations (1). Track 3 in the image below.
    2. Select the No Opacity (2) animation effect for the fade-out.
    3. Drag and drop the No Opacity effect (3) to the point in the track where you want to fade-out. Adjust the start and end point of the fade using the handles on the animation arrow.
    4. Select the Full Opacity (4) animation effect for fade-in.
    5. Drag and drop the Full Opacity effect (5) to the point in the track where you want to fade-in. Adjust the start and end point of the fade using the handles on the animation arrow.

    fade in and out
    Figure: Camtasia - Steps for adding fade-out/fade-in animation to video track of your face in 'Done' video

    Tip #4: Camtasia's Final Step – Export your video

    Follow the steps to export your video:

    1. Click the Share button on the top right of the window

      export video1
      Figure: How to share

    2. In the new dialog, select 'Custom production settings':

      export video2
      Figure: Production settings

    3. In the next window, uncheck the ‘Produce with controller’ option:

      export video3
      Figure: Controller settings

    4. In the ‘Video settings’ tab, copy these settings:
    5. Frame Rate: 30
    6. H.264 Profile: High
    7. Encoding mode: Quality
    8. Increase the quality to 100%

      export video4
      Figure: Copy these video settings

    9. In the ‘Audio settings’ tab, make sure the Bit rate is set to 320 kbps:

      export video5
      Figure: Audio settings

    10. Click Next and save your file!

    Example of a good Done Video

    Video: Good example - Record yourself and your screen | SSW Error Handler (4 min)

    Looking to improve your videos?

    Once you've followed the steps above to set up your device and you are ready to record, see our tips here for the key steps to make a great 'Done Video'

  44. Do you know when you use @ mentions in a PBI?

    When the Product Owner verbally requests a change to a PBI, how do you update the PBI to reflect the change and also keep track of the conversation?

    You could send yourself a "To Myself" email and update the PBI description accordingly, but only those people included in the email chain are aware of the conversation. Only send a "To Myself" email when there is no Product Backlog that is related to the request, otherwise you should create or update a PBI and @mention the Product Owner and other relevant people (@mentioned people will still receive an email).

    bad mention pbi
    Figure: Bad example – Don't use emails to update tasks

    Instead, what you should do is use the discussions feature in the PBI and mention the user using "@username".

    The benefits of using descriptions and comments on PBIs:

    • Quick and easy, no need to compose an email
    • History is visible to anyone looking at the PBI (with email, if you don't cc them, they wouldn't have a clue)
    • Easy to see all important information in one place, instead of digging through email

    When someone (especially the PO) asks you to work on a PBI, @mention that person in the PBI description/comments so they get notifications about the tasks.


    You are replying to "Hey, can you please fix PBI 123?"

    "I have found the PBI and moved it near the top of our backlog"

    Bad example - No @mention used

    "I have found the PBI, prioritized it near the top, and @mentioned you so you know when it is fixed"

    Good example - @mention included

    GitHub Issues

    MicrosoftTeams image
    Figure: Good example – Using @ mentions in GitHub

    Tip: You can @mention on your pull requests as well.

    Azure DevOps PBIs

    To create a new PBI in your Azure DevOps project:

    1. Navigate to Boards | + New Work Item and select the type that best suits your item
    2. Enter your PBI title
    3. @ mention your desired user in the description

    good mention pbi
    Figure: Good example – Using @mentions in Azure DevOps discussion

    pbi mention email
    Figure: Good example – Email still gets sent to the users who are mentioned in the discussion, so they can still chime in if any details are incorrect

    It is also good practise to use @mention in the discussion to track changes and request test pleases. Try formatting your mentions like an email to clarify both accountability and responsiblity and identify the current status of the project.

    pbi formatting mentions
    Figure: Good example – Using "Cc" and Greetings as you would in an email. Emojis are helpful too! 😊

  45. Scrum – Do you know where to discuss the backlog?

    When discussing a PBI/Issue, Pull Request, or a project in general, it is important to do it in the right place.

    Kanban on Screen

    bad mention pbi 1710232021933
    Figure: Bad Example – don't use emails to discuss tasks

    For code

    Sometimes developers need to discuss code implementations - sometimes to improve the code, other times to explain why something was done a certain way.

    This should be done in the Pull Request, if possible comment directly on the line of the code change and once resolved, make sure that the important information is captured in the merge's commit description.

    comment on code in pull request
    Figure: You can add a comment on a specific line of code

    For a new PBI/Issue

    As perDo you know when you use @ mentions in a PBI? - Create a new issue mentioning the Product Owner and the related people

    Create Issue
    Figure: Good Example - When adding a GitHub issue, @ mention the Product Owner and other related people so they receive a notification e.g, an email

    For an existing PBI/Issue

    Discuss it in the existing PBI/Issue.

    existing issue discussion
    Figure: You can discuss an existing issue, even when it has been closed

    For other topics (brainstorm ideas, general discussion, etc.)

    You can:

    • Create a PBI/Issue

      • use a "discussion" label so that others know that it is just a discussion point and not actionable work yet
      • have it checked by the client before publishing it (recommended)
    • Discuss it in the discussion tab in GitHub

    Discussion Tab in GitHub
    Figure: You can create discussions on your project using the Discussion tab in your GitHub repository

    • In the team channel in Teams

    Team channel
    Figure: You can discuss your idea in Teams on the team channel

    In summary, Email should be the last resort.

  46. Do you know which emojis to use in Scrum?

    Emojis make it easier for people to quickly workout what type of content is coming up and to highlight important stuff. It works nicely for meetings, backlogs, and more.

    An easy and fun way to have use emojis consistently in Scrum is to follow the list on scrumoji - An emoji guide for your agile communication.

    Tip: Use the "Windows Key" + "." to see the emojis in your screen.

    Document it

    If standard emojis aren't defined in the project documentation then new starters will be confused about what emojis to use. That adds cognitive load and makes the process more trouble than it's worth for developers.

    So creating documentation that outlines the standard set of emojis to use is crucial. Then developers can just pick the emoji that most closely fits their PBI. For example, you might have the following emojis defined:

    💄 UI

    📃 Documentation

    🐛 Bug

    ✨ New Feature

    🔍 Investigate

    📈 Report

    ⚒️ DevOps

    🎥 Video

    ♻️ Refactor

    Try not to go overboard, keeping it simple makes it easier for developers to pick the right emoji.

    srumoji   bad example
    Figure: Bad Example - The Sprint Review is an important meeting but doesn't stand out in my calendar

    scrumoji   good example
    Figure: Good Example - The Daily Scrum and Sprint Review stand out and I will definitely not forget to attend

  47. The Team - Do you encourage multi-skilled teams by leaving your comfort zone?

    When selecting their tasks, team members should be looking to extend their skills. Scrum encourages multi-skilled workers, rather than having testers, back-end developers, designers etc. In other words, all team members should be able to help completing any task.

    This does not imply that everyone is a guru in everything; no doubt some people are especially skilled in a specific area, but team members work together and should be learning new skills from each other.

    During task generation and estimation in Sprint Planning, choose something new and ask someone experienced in that area to have a subtask to help you.

    This is to make the team multi-skilled and reduce dependencies on individuals.

  48. Do you work in vertical slices?

    As a Software Developer you will work with both frontend and backend. When working in teams, it is common to split the work into what people's strong suits are. This can be beneficial but it comes with a flaw of not helping developers strengthen their weaker skills.

    Let's look at a way to help strengthen your team members weaker skills...

    You should do a whole slice of work each time (from the frontend to the API, and any extras in between).

    Part of Scrum means all developers are responsible for the work that is conducted during a Sprint. To push this point, as part of definition of done, adding 2 developers to look over the code helps with:

    • The quality of code to remain high
    • Allowing all developers to learn (Even those reviewing)
    • Teaching the author of the PR
    • Asking questions
    • Reducing the risk of knowledge gaps across the project as more people learn about the different areas of the code base

    vertical slicing
    Figure: Vertical slicing is just like a slice of cake!

  49. The Team - Do you help your Scrum Master protect and serve The Team?

    Part of the Scrum Master's (not ScrumMaster's) role is to protect the team from distractions so they can deliver on their commitments, to ensure agreed process is followed and to help all roles keep their promises.

    It is also important that team members do not allow themselves to get distracted and must work based on priority.

    Here is a good saying to remember: "It is very important I complete my Sprint. Can this wait 1 week until the next Sprint?".

    Video: What is a Scrum Master?

    Any requests for work or distractions outside the scope of the project that take more than 15 minutes must be declined politely and the distraction notified to the Scrum Master, or, if the request comes from the Product Owner, it can be added as a new PBI as per how to handle unexpected requests in the middle of a Sprint.

    The only exceptions, where a Team Member can start the work before notifying the Scrum Master are:

    • Any critical production issues that absolutely requires the attention of the Team Member and nobody else is available
    • A client request for work when the Team Member is working on an internal project
    • Test please requests, if the total time taken from the Sprint for all Test Please requests is less than 8 hours

    In these 3 exceptional cases only, even if the Team Member doesn't get a response from the Scrum Master, the requestor can insist that the member starts the other work immediately.

    Video: Richard Hundhausen’s advice to Scrum Masters

  50. The Team - Do you have a Scrum Master outside the Dev Team?

    Pure Scrum dictates that the Scrum Master could be one of the developers on the team, but we find this is hard for a developer as he will be split between trying to do the work himself, while also ensuring that the Team still uses Scrum properly.

    We find that a better option is to use a separate Scrum Master so his only responsibility on the project is to ensure Scrum is used well and the Product Owner is informed of any developments.

  51. Planning Meeting - Do you encourage Spikes (aka investigation tasks) when a PBI is inestimable?

    Sometimes it can be unclear to The Scrum Team whether a PBI can be completed as required. For example the PBI "automatically package with Wise after the automatic build" requires investigation and experimentation to see if this is possible and to provide a meaningful estimate for the original.

    ProjectManagement DigaLittleDeeper
    Figure: Schedule time to dig a little deeper. There's always another layer to uncover

    How is experimentation done? In Agile software development, when you have an unknown, you do a spike PBI. A spike is a time boxed investigation with the output being the answer to an experiment or investigation and the resolution of an estimate for the original PBI.

    It is then best to write a new PBI “Investigate whether it is possible to automatically build with Wise”. This PBI can be more accurately estimated and the result will allow the original PBI to be estimated or revised.

    RuleEncouragingInvestigationStoriesBad Figure: Bad example – I want you to implement something, but I am not going to tell you what it is. How long will it take?

    To embark on the original PBI when it is inestimable would be irresponsible and leave The Team with a potentially impossible PBI and the risk of a failed Sprint.

    All investigating PBIs must be timeboxed, otherwise the process of investigation can meander and never come to a conclusion.

    RuleEncouragingInvestigationStoriesGood Figure: Good example – The spike (time boxed investigation) comes first as it is impossible to estimate implementing something you do not know

    Note: This gives you work for future Sprints

    Tip: There is a further benefit of tagging 'spike' tasks with a consistent label. If your company takes up R & D tax incentives, then you need to be able to query for activities that were 'of an experimental nature'. In Australia this is a 15% credit on each dollar you spend on a developer.

  52. Do you have a war room? (summary)

    The Scrum team needs a place to gather for all the Scrum ceremonies. This room should have useful information on the wall to help the team work more efficiently. We recommend having the following:

    Note: For co-located teams only.

    war room bad example
    Bad Example – No Product Roadmap is on the wall, so people can be out of sync with the future plans of the Product Owner

    war room good example
    Good Example – The Product Roadmap is visible at a glance

  53. The War Room - Does your development room have an electronic task board?

    Having an electronic task board makes it easy for developers to keep track of tasks.

    These are the 3 columns (aka swim lanes) you need:

    • To do
    • In progress
    • Done

    TFS Preview Task Board
    Figure: Good example - a virtual client task board in action

    Physical is OK too for small, co-located teams.

    Figure: OK example - a physical client task board in operation

    Near your task board, stick an SSW "Want to submit a User Story?"

    • Where to find their project portal
    • Who to contact with questions
    • How to add tasks to the task board

    Print out this PDF and fill in the 2 fields and stick it on own task board.

    Figure: Create an avatar for each person and stick them on the current task. You can find our User Story Cards here. You can write the Azure DevOps Work Item ID on each card

  54. The War Room - Does your Scrum room have the best Scrum image?

    We all know that a visual image can make a complex process easy to understand. Having a visual image of the Scrum process helps everyone, including the Product Owner and interested stakeholders, understand the process and make sure the steps are being followed.

    Here is an image for your war room wall...

    SCRUMImage bad02
    Figure: Bad example - This image doesn't include the review and the retro

    SCRUMImage good
    Figure: OK example - This Scrum image is OK because it includes all the important steps including the Review and the Retro

    8Steps preview
    Figure: Good example - This Scrum image includes all the important steps from the initial meeting to the Review and Retro

    Find and print the PDF on the "SSW 8 Steps to Scrum" rule, then put it on your 'War Room' wall.

    If you like this, retweet:

  55. During a Sprint - Do you know when to create bugs?

    This is a very common question asked of teams using Scrum. The answer can depend on a lot of things, such as:

    • How big is the bug?
    • Can it be fixed right now?
    • How important is quality to the product?
    • Are there dedicated testers as part of the team?

    Regardless of your answers, there are basically 2 types of bugs:

    • Found in code currently being developed (in-Sprint), and
    • Found in code previously thought done (out-of-Sprint).

    In-Sprint bugs

    For stories that are in progress, there are some guidelines:

    Typically you want to fix all bugs discovered during the Sprint or else they could impact the team’s ability to achieve the Sprint goal:

    • If it’s a small bug (< 1 hour to fix) and taking the time to fix it won’t impact the burndown, then just fix it
    • If it’s a larger bug (> 1 hour to fix) and taking the time to fix it won’t impact the ability to achieve the Sprint goal, then create a Bug work item, associate a Task and have a team member perform the fix during the Sprint
    • If it’s a larger bug (> 1 hour to fix) and taking the time to fix it will impact the ability to achieve the Sprint goal, then create a Bug work item to be prioritized (by the Product Owner). This prioritization will decide whether the fix occurs in the current Sprint. Note that whether the bug is fixed in this or a later Sprint, you may not be able to achieve your Sprint goal
    • If another team member finds the bug, then they should create a Bug work item and then the team decides if it can be fixed in the current Sprint or needs to be prioritized (by the Product Owner) to be fixed in a later Sprint, in which case you may not be able to achieve your Sprint goal The team decides how many hours "n" equals

    Out-of-Sprint bugs

    For stories that the team had previously considered done, here are some guidelines:

    • If the bug is not critical (i.e. a hotfix), then create a Bug work item to be prioritized and fixed in a later Sprint
    • For a critical hotfix, do whatever needs to be done to get the fix into production, knowing that your current Sprint commitments may be impacted. Adjust the team’s capacity accordingly, especially if lots of hotfixes start occurring Tip: Don’t create an associated task to fix a bug until the Sprint in which the team commits to fix it starts

    See rule on Do you know how to handle bugs on the Product Backlog? for how to work with bugs on your backlog.

    Source: Extracted from Accentient’s Scrum Training by Richard Hundhausen.

  56. Do you know how DevOps fits in with Scrum?

    DevOps and Scrum compliment each other very well. Scrum is about inspecting and adapting with the help of the Scrum ceremonies (Standup, Review, Planning and Retro). With DevOps it's all about Building, Measuring and Improving with the help of tools and automation.

    2016 06 08 14 33 24
    Figure: Traditional Scrum process

    2016 06 08 14 30 33
    Figure: Scrum with DevOps

    With DevOps, we add tools to help us automate slow process like build and deployment then add metrics to give us numbers to help quantify our processes. Then we gather the metrics and figure out what can be done to improve.

    For example with Exception Handling, you may be using a tool like or Elmah and have 100s of errors logged in them. So what do you do with these errors? You can:

    1. Add each one to your backlog
    2. Add a task to each Sprint to "Get exceptions to 0"

    The problem with the above is that not all exceptions are equal, and most of the time they are not more important than the planned PBIs being worked on. No developers like working a whole Sprint just looking at exceptions. What should happen is:

    1. Have the exceptions visible in your development process (i.e. using Slack, adding as something to check before Sprint Planning)
    2. Triage the exceptions, either add them to the backlog if they are urgent and important
    3. Add ignore filters to the exception logging tool to ignore errors you don't care about (e.g. 404s)
    4. Prioritize the exceptions on the backlog

    The goal here is to make sure you're not missing important and to reduce the noise. You want these tools to help support your efforts and make your more productive and not just be another time sink.

  57. Do you use printed 'SSW Story Cards' with your customers in the Spec Review?

    When doing a Spec Review, always bring printed pdf file SSW Story Cards.

    • Complete the story card with the client
    • Teach the clients how to complete story cards by themselves
    • Go to Project Portal (E.g. Azure DevOps or GitHub) and enter the story
    • Write the Story ID field on the card
    • Stick the cards on the project room wall maximizing visibility

    Figure: SSW Story Card

  58. Do you know your agility index?

    So you’re agile… or are you? Find out what you’re doing right and what things you can improve on by taking our quiz and finding out your agility index. Do this at each of your Sprint retrospectives and ratchet up the quality with each Sprint

    What’s My Agility Index? HowAttractiveAreYou.docx

  59. Do you know the whole Scrum team is responsible for quality?

    In a Scrum team, every member of the team has some responsibility for the quality of the deliverables of the team.

    If you have a dedicated tester embedded in the Scrum team, they are not solely responsible for performing all of the types of testing required to help build a quality deliverable.

    award winners
    Figure: The whole team needs to take on responsibility to achieve great quality (source:

    The idea of adopting a "whole team approach to quality" is to build quality into the software rather than trying to test the problems out of it at the end.

    build quality in
    Figure: Wise words from Deming on achieving higher quality

    So, what is "quality"?

    There are many definitions of "quality". A simple but very useful definition is:

    Quality is value to some person(s) who matter(s)\

    • Jerry Weinberg (with changes by Michael Bolton & James Bach)

    This definition highlights the fact that quality is a relationship between the user and the product - it's not the product itself, nor an element of the product. The user's perception of value is also subjective.

    Acknowledging the subjective nature of quality is important, so that we don't fall into the trap of trying to measure it. Quality is more amenable to assessment than it is to measurement.

    Testing ≠ quality

    This might be hard to swallow but, just like weighing yourself doesn't cause you to lose weight:

    Testing does not improve quality

    Testing provides valuable information about the software - and the processes involved in creating it, building it and deploying it - and it is only by acting on this information that quality may be improved.

    The whole team approach

    Every member of the Scrum team has their part to play in building quality into their deliverables. There are different kinds of testing activities that rely on different skills found across the various people making up a diverse Scrum team.

    This mission statement from Atlassian is a good expression of the aim of modern testing and quality management:

    "We want to help ship awesome software, not just prevent poor software from being released" Atlassian Quality Engineering group mission (from job advertisement, April 2020)

    The idea is not to rely on someone with the role/title of "tester" to do all of the testing work!

    Some examples follow of how the different roles in a Scrum team contribute to quality.


    By writing unit tests, developers enable fast feedback on code changes so that low-level problems can be identified quickly and resolved before impacting customers.

    Code reviews can help to prevent problems from even being committed to the source code repository and adhering to coding standards helps to maintain good quality at the code level.

    Scrum Master

    With their key responsibility to remove blockages, the Scrum Master actively contributes to quality by ensuring that development can continue unimpeded. Any context-switching resulting from blockers increases the risk of problems being introduced.

    Keeping the Scrum board in an accurate state also assists from a quality perspective, so that the developers are working on the right things at the right time, building the highest value software for our customers.

    Product Owner

    The availability of a Product Owner to provide quick and accurate feedback and answers to team members' questions is critical to building a quality product. With their focus on priorities and defining the stories to implement, the Product Owner helps to build the right thing for our customers with quality in mind.

    Tips for building quality in

    Think "testing", not "tester"

    Testing is an activity and can potentially be performed by different members of a Scrum team, e.g. developers might write unit tests, testers might perform exploratory testing.

    By thinking in terms of the activity, "testing", rather than a person or role, "tester", it becomes more obvious that the responsibility for testing spreads across the whole Scrum team.

    Turn testing problems into problems for the whole Scrum team to address

    When faced with a testing problem in the team, make it the whole team's responsibility to find solutions. Even if you have a tester embedded in the Scrum team, they might not be the best person to solve a testing problem.

    For example, suppose the software has poor testability that could be enhanced by adding hooks, APIs or logging. Assigning the work to add these testability features to a developer is probably more appropriate than giving it to the tester.

    Focus on preventing misunderstandings about feature behaviour as well as preventing defects in the code

    Good practices such as code reviews and static code analysis can help to keep the codebase in a high-quality state. But having great code doesn't mean you end up with a great product!

    Focusing solely on "building it right" is only half the story, so actively take steps to ensure you're "building the right thing". Working towards a shared understanding of what it is you're building (and why) can help to prevent costly rework and dissatisfied customers.

    Use diverse perspectives from the whole team to gain a better understanding of risk

    Building an understanding of the risks involved in delivering a feature is not easy, but it's made easier by utilizing diverse perspectives.

    Testers are generally skilled in risk analysis and so can be highly valuable in this process. But developers are likely to be great at thinking about technical risks and business stakeholders are awesome at identifying business risks, so make use of a diverse group to more fully understand risk.

    This information is critical in formulating testing strategies to mitigate the identified risks. Remember, "Risk is what's left over after you think you've thought of everything" (Carl Richards, The Behavior Gap).

    Perform diverse testing activities


    • Having conversations to build shared understanding
    • Asking questions to test ideas and assumptions
    • Automating tests
    • Performing exploratory testing
    • Testing for quality attributes such as performance, reliability and security
    • Learning from production usage

    Use whole team retros and small experiments to continually improve testing and quality and find out what works in your context.

    Deliberately adding an item for testing and quality onto your Sprint Retro agenda can be helpful as a reminder.

    The Agile Testing Manifesto

    Many of the mindset shifts required to think in terms of a whole team approach to quality are nicely encapsulated in the Agile Testing Manifesto (which is deliberately phrased in a similar way to the Agile Manifesto).

    agile testing manifesto
    Figure: The Agile Testing Manifesto, by Karen Greaves & Samantha Laing

    Some anti-patterns

    There are some common anti-patterns that indicate a Scrum team is not taking a whole team approach to quality.

    The "testing phase"

    If you still refer to a "testing phase", it's likely that testing is not seen as an activity but rather a stage or phase.

    Testing should be a continuous process, working alongside development and performing appropriate types of testing at the right time throughout story development.

    Asking "how did QA miss this bug?"

    If a bug finds its way into production and is reported by a customer, asking this question implies that only testers are responsible for testing, rather than the whole team. It's worth remembering that testers don't put the bugs into the code!

    A more productive question to ask is "How can the whole team make changes - to its development, testing and deployment practices - to avoid similar issues leaking into production in the future?"

    Testing a Sprint behind development

    If stories are considered "finished" when the code is done but testing still needs to be performed in the next Sprint, then the team is still viewing coding and testing as separate, rather than concurrent, activities.

    This problem is most commonly seen for automated tests, where the story is coded and tested (by humans) in the Sprint but the effort to create good automated tests is deferred to the next (or another future) Sprint. This accumulates technical debt and adds untested code into the codebase, so is not a good practice.

    Remember that all planned testing should be completed for a story as part of its Definition of Done, meaning it needs to be done in the same Sprint as all the other work for the story.

    Focusing on meeting the Sprint commitment over meeting the DoD

    While the goal is to meet the Sprint commitment, this goal shouldn't be achieved at the expense of quality. The DoD is there to help achieve a consistent, desired level of quality by detailing all of the work to be done before a story can be considered complete.

    Calling a story done in order to meet the Sprint commitment and then fixing known defects later is a false economy - this practice leads to the deliberate accumulation of technical debt, which costs more to pay down later.

    If nothing else, calling a story "done" when it's not done is just cheating - and cheats always get found out, eventually!

  60. Do you use meaningful PBI titles?

    Product Backlog Items (PBIs) are the cornerstone of a well-oiled project. They track features, bugs, tasks, and much more. When a developer or Product Owner is looking through the backlog, it's important that - at a glance - they can read the titles of PBIs and have a decent understanding of them.

    So what separates a good PBI title from a bad one?

    Video: Do you use meaningful PBI titles? | Luke Cook | SSW Rules (5 min)

    Note: Usually, we use the term PBI to encompass all types of backlog items, including those related to DevOps, Trello, GitHub, or any other platform.

    How to create meaningful, yet efficient titles?

    Without a meaningful title, you need to drill down into the details. If your backlog is substantial, it quickly becomes time-consuming and tedious to drill into each and every item to see what it's about. Even worse... next time you visit the backlog, chances are you won't remember the details and will have to re-read every PBI again!

    Fix menu bug

    Figure: Bad example – What bug? How important is this?

    ❗️ IMPORTANT 🐛 BUG | Menu disappears on mobile devices

    Figure: Good example - "Important" emoji and text to bring attention to the PBI's importance, "Bug" emoji and text to indicate the PBI type, with a clear description of the issue

    ❌ Don't

    • Be generic (e.g. "Fix bug in site")
    • Write a novel in the title
    • Ignore the importance of urgent PBIs

    ✅ Do

    • Be specific (e.g. "{{ AREA }} | {{ BEHAVIOUR }}"). See our rule to order of instructions
    • Prefix - Identify its urgency (e.g. ❗️ IMPORTANT)
    • Prefix - Identify the type (e.g. 🐛 BUG)
      Note: Bugs are special case - they should have greater visibiliy
    • Use emojis. See our rule on emojis in Scrum

    Good PBI titles examples

    Using this structure: {{ EMOJI FOR PBI TYPE }} {{ BUSINESS AREA TOUCHED }} | {{ SHORT DESCRIPTION }}


    🐛 Newsletter form | returns HTTP 500


    ✨ Newsletter form | Validate email address


    💄 Header | Update site header with new logo


    👷‍♂️ DevOps | Add ephemeral deployment slots for PRs

    Urgent tasks:

    ❗️ IMPORTANT 🐛👷‍♂️ SysAdmin | Northwind app inaccessible through company VPN

    Other examples:

    🐛 Invoices | Invoice totals are rounded incorrectly

    ⚒️ Infrastructure | Implement staging deployment pipeline

    ✨ Clients page | Add create/edit client fields

    Great titles are also important on Pull Requests, and email subjects.


    Love them or hate them, emojis have become a staple in the development world. As the old saying goes... "a picture is worth a thousand words". You can use emojis (responsibly!) to categorize PBIs/Issues/PRs/Emails, as well as bring attention to important items in a way that is easily interpreted by other people.

    Regardless of whether or not you choose to adopt the emoji language, you should always be mindful of the title's text.

    Always ask yourself: "Can a developer (or Product Owner) interpret the task and its importance without needing to dive into the details?"

  61. Do you have a Product Backlog refinement meeting?

    When a Scrum Team meets for Sprint Planning, they want to plan out the next week's work so they can get cracking on improving the product.

    The Problem - Sparse PBIs

    The team often runs into a roadblock when they find that the Product Backlog Items (PBIs) are lacking in basic details.

    This problem leads to 1 of 2 outcomes:

    • Poorly defined PBIs being added to the Sprint causing problems with shaky estimates and later down the track when developers are unclear about these PBI details and how to implement them
    • A lengthy Sprint Planning meeting (with only a few people engaged) while refining these PBIs

    The Solution - Product Backlog refinement meetings

    You can avoid these scenarios by having well defined PBIs written in advance so the Sprint Planning session is simply a tick and flick.

    The Scrum Guide mentions the process of refining the Product Backlog as the core way to avoid these issues. Product refinement involves breaking PBIs into smaller and more manageable units of work with precisely defined requirements. This process ensures that work involved with each PBI is well defined and measurable that the outcomes of completing them are measurable. A Product Backlog Refinement meeting is a great way to ensure the Product Backlog is regularly refined. In this meeting, the Tech Lead and another developer refine all the PBIs.

    This process involves refining the PBIs in the backlog and adding a "Ready" tag or status when the PBI has met the Definition of Ready.

    To ensure the Product Backlog Refinement meeting runs. Setup a recurring meeting with the following agenda: