Category Archives: Communication

What’s the What?

I recently parted ways with my Scrum teams in order to pursue an opportunity another company. One of the team members asked for general feedback about how the team had been doing. Here is my response:

Team,

I have always been open with you about things we are doing well and areas where we need to improve as a team, so instead of specific criticisms or suggestions, let me leave you with a few words of wisdom:

Always ask yourself, “what’s the what?”

Always ask yourself, “why?”

As a technical person, it’s easy to jump to the solution before really understanding the problem. Instead, always strive to understand what user or customer wants and why they want it before deciding how to solve the problem. How is this put into practice? An easy way is via user stories that reflect what the user is trying to accomplish rather than a technical solution. It could be a business task the user is trying to accomplish or a business goal that they are trying to achieve.

The beauty of agile is that you, as technical people, are not only empowered to ask these questions but are expected to. If anyone ever tries to tell you that you should not be concerned about the “what” or the “why”, do not accept that answer. Your users and customers will be much better off when you understand their needs.

Cheers!

Alec

Retrospectives – Back to Basics

Retrospective

For a new Scrum Master, the mechanics of getting started with retrospectives are deceptively easy. Somebody tells them to write three columns on the whiteboard (What Went Well, What Did Not, Ideas) and to facilitate the discussion. The Scrum Master makes sure that management is not invited to the meeting. He/she Identifies the team members who are not participating and try to get them talking. Simple. The retrospective becomes a blend of problems mixed with solutions and “action items” for the next sprint. If the team is lucky, it identifies the most valuable areas for improvement. Unfortunately for many teams, they go through the motions but do not get to the heart of their biggest problems/opportunities. It becomes a stale ritual and the team plateaus.

Surprisingly, many Scrum Masters fall short on the basics of how to conduct a retrospective. They think that all it takes is writing the three columns on the board. Properly done, it actually starts as soon as sprint planning is done.

In their book “Agile Retrospectives – Making Good Teams Great”, Esther Derby and Diana Larsen suggest the following structure for a retrospective:

  1. Set the stage – get the team in the right mindset for a retrospective
  2. Gather data – identify the key things that happened during the sprint
  3. Generate insights – about those things and why they happened
  4. Decide what to do – new practices to improve
  5. Close the retrospective – take a minute to step back and reflect on the sprint, the team’s accomplishments, and the retrospective itself

Lots of different techniques exist for each of the stages of a retrospective. The art is in the Scrum Master recognizing which one fits the team at that particular moment in time.

To set the stage for the retrospective, the Scrum Master may remind the team that the retrospective is a safe environment. They could also do a check in where they go around the room and ask each person “How are you doing today?” to engage the team. Another technique is to ask people “if the team were a car, what kind/make/model of car were we in this sprint?” and record each person’s answer on the board. This can provide an interesting reference point to revisit if someone says the team was a Pinto but during the remainder of the retrospective does not point out any problems that occurred during the sprint.

In gathering data about the sprint, the Scrum Master and team consider:

  • The sprint goal
  • The sprint backlog and the results (done, not finished, etc) for each story.
  • Impediments or challenges that occurred during the sprint. Laying them out on a calendar can help illustrate how they affected the sprint and generate conversation for how to handle them in the future (the Scrum Master may get in the habit of noting these as they happen).
  • Is the team going through a storming phase? Asking team members to track how they were feeling about the sprint during specific stages of the sprint can help surface opportunities for working agreements, practices the team should adopt, etc.
  • After trying to remember what happened over the last week or two (they know better than to do three or four week-long sprints) the team and Scrum Master may start to note some events as they happen to make data gathering easier in the retrospective.

To generate insights, the team can approach the discussion a number of different ways:

  • Was every story closed? If not, what state was each one in at the end of the sprint? Ask why. Then ask why again.
  • Did the team stretch yet still meet the sprint goal? Reflecting on what the team did well could reinforce those practices and also set the stage for a discussion about how to take it to the next level.
  • Is there a lot of discussion about whether the team should adopt certain practices? The insights could be focused on things the team to start doing, stop doing, and continue doing.

Teams are usually pretty good at coming up with ideas for how to do things differently. Trying to do all of them at once or forgetting about them in the throes of the next sprint are common pitfalls.  A good Scrum Master will gather these ideas as the team identifies them during the retrospective. A great Scrum Master will sense when the team has not really gotten to the heart of an issue or opportunity and prod them to drill down to the heart of the matter.

Once the team has identified ideas or new practices to try in the next sprint, posting them near the Scrum board is an easy way to quickly remind the team about them when the team is gathered around the board during the daily standup. The remaining ideas go into the Insight Backlog. This backlog can be evaluated along with new ideas that come out of each retrospective to decide which ones to try next.

Some formats for gathering data and generating insights include:

  • (Old reliable) What Went Well, What Did Not, Improvements. Team members write ideas on sticky notes and put them in the respective columns. Dot voting for which ideas to adopt.
  • Reviewing results for each story, conducting 5 whys for each one.
  • Start Doing, Stop Doing, More Of. Again, sticky notes placed by team members can help with participation.
  • Sailboat. What things are the wind in the team’s sails, propelling it? What are the anchors that are slowing it down? Another variation is Motorboat, where the team identifies the anchors that are slowing down the boat (team) and they can even place them a different ‘depths’ to indicate their severity.

Reflections

  • There are many ways to conduct a retrospective. The Scrum Master’s job is to find the right way to help the team improve at that particular moment in time.
  • Overcomplicating the format of the retrospective can get in the way of improvement.
  • Letting the format of the retrospective get stale can result in team members who have shut down from boredom before they even enter the room.
  • The Product Owner should be there. They are a member of the team after all.
  • In closing the retrospective, take time for Appreciations. Good people aren’t just working for a paycheck.

Backlog Grooming: Scrum’s Red Headed Stepchild

Backlog grooming differentiates good scrum teams from ones that are just scraping by. Viewed by some people as optional, there is often a temptation to skip it in favor of remaining focused on the current sprint. Experienced teams understand that backlog grooming can have an impact not just on the next sprint planning meeting but on the extent to what they build meets user needs.

What is backlog grooming?
The team reviews stories or epics in the backlog to be done in future sprints. The Product Owner (PO) explains the stories, the team asks questions, and additional story information may be captured as a result of the conversation. The PO may leave the meeting needing to gather additional information from users or customers about the story. The team may identify research spikes needed to understand the technical approach for the story. Typically the focus is on stories for the next sprint, but if those are well enough understood the focus may be on stories or epics further down in the backlog. The team may also adjust the sizing of stories based on what they learn during grooming. Large stories may be split into smaller ones, especially if they are going to be in the next sprint.

Note that backlog grooming can also be called “backlog refactoring”. My personal preference is to avoid the term “refactoring” because in some organizations new to agile, “refactoring” is still a dirty word associated with something that needs to be reworked because it was not done correctly the first time.

Why is it important to do on a regular basis?
I once worked with a Scrum team that literally took an entire week to finish a sprint plan. The team did zero backlog grooming. The sprint planning meetings were a combination of the PO identifying new user stories, the team members asking questions, delays while the PO sought answers, and delays while the team researched the feasibility of certain options. The end result was stories and sprint plans full of vagaries and risk. Contrast this with a team that does backlog grooming on a regular basis. Questions surface during the discussion and those questions are either answered immediately or the PO and team have time to research the answers. By the time sprint planning rolls around, most of sprint planning is about HOW the team will build it and not WHAT they are supposed to build. The PO and team can create a sprint plan to which they can commit.

How often should backlog grooming by done?
Backlog grooming should be a weekly meeting. Each meeting should be at least one hour long. A rule of thumb is never to do backlog grooming on the first or last day of a sprint. One the first day of the sprint the team is eager to get rolling the new sprint’s stories; on the last day of the sprint they may be focused on finishing off the last few sprint items. The last thing we want is for grooming to be perceived as getting in the way of the team’s success. Also, a few days may be needed after grooming to get answers to questions.

For a team that runs two week sprints starting on a Monday and ending on Friday, every Wednesday would be a perfect day for backlog grooming.

Who attends backlog grooming meetings?
The Product Owner, the Scrum Master, everyone on the team, and business representatives as needed. It is key for all of the scrum team members to attend so that they all have a good understanding and commitment to each story. Because a story is partly what is written down and partly a conversation, team members cannot expect to skip grooming and then catch up by reading the stories.

What is the PO’s role in backlog grooming?
The Product Owner’s role in backlog grooming starts before the actual meeting. The PO ensures the story prioritizations in the backlog are correct so that they know what stories will be groomed. They add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. While these are basic PO responsibilities, they are sometimes overlooked or ignored because of customer meetings, management presentations, etc. Regularly-scheduled grooming meetings are a great way for the PO to establish a personal cadence of prepping stories for backlog grooming.

A few days before backlog grooming, the PO tells the team which stories will be covered in the upcoming grooming meeting. This gives team members a chance to take a look at the stories ahead of time and either start thinking about the stories and possibly come prepared with questions.

The PO typically runs the grooming meeting.

What is the Scrum Master’s role in backlog grooming?
The Scrum Master can help out the PO by scheduling the meeting and taking care of meeting logistics. More importantly, the SM can ensures that the PO is on top of the backlog prioritization and knows what will be groomed. As a Scrum Master, I worked with a PO who was chronically ill-prepared for backlog grooming meetings. I addressed this via pre-meetings with her a few days before backlog grooming to help her get into the habit of prepping the backlog for grooming.

What is the team’s job in backlog grooming?
If possible, team members take a look at the stories to be groomed before the actual meeting. In the meeting, they seek to understand the requirements by discussing and asking questions. The PO may provide 50% of the story content before the grooming session. Good discussions will round out the acceptance criteria as the team and PO look at the story from different perspectives.

Reflections

  • Backlog grooming is an essential activity. Resist the temptation to skip it.
  • Schedule grooming meetings so that they fit In the middle of the weeks of the sprint.
  • The entire team should be involved in grooming.
  • Regular backlog grooming helps the PO establish a cadence for working on stories.

The Heartbeat of an Agile Team

What is the one focal point that catches every team member’s attention at the same time every day?  Of course it is their Scrum board. Some teams go through the motions and use their Scrum board because they are told to; for effective teams the board is a way to collaborate, manage work in process, keep track of impediments and know whether or not they are going to meet the sprint goal. Effective teams turn their board into a highly-visible collection of critical information about their effort. It becomes the heartbeat of the team and helps set the cadence for each sprint.

Their board might look something like this:

Board

 

Sprint Dates and Goal – as a reminder of the goal and the timeline. Seeing the sprint dates can be helpful if users who will be testing attend the standups so that they understand the sprint timing.

Columns for each step in their development process – This can be as simple or as complex as the team wants – it usually evolves as the team learns and tweaks its process to ensure a smooth flow of stories. In the example above, the team experienced issues with too many stories waiting for user testing. They created a column to show which stories are ready for user testing to make it clear to users when something is ready for them to test. During standups, the Scrum Master points out any columns where an excessive number of stories are piling up. Even with Scrum, the team may set limits for how many stories may accumulate in each column before team members swarm to address a bottleneck.

Sprint Calendar – during sprint planning the team members estimate on which days of the sprint they think stories will be Done and also when they will likely reach any other significant milestones in the team’s process such as being ready for user testing. This is a way of performing a sanity check for the sprint plan.  It is also a way for the team to gauge whether or not it is on track during the sprint. When user testing is part of the Definition of Done, it allows the users to plan when they will be performing this testing. Putting team members’ planned vacation days on this calendar avoids surprises in the middle of the sprint. It can also help to put key SME’s or users’ vacation days on the calendar if these could impact the sprint.

Impediments – unresolved impediments. Making these visible is a way to track them and may have the side benefit of prompting outside stakeholders who attend the standup or visit with the team to help the Scrum Master by finding other ways to resolve them.

Additional Stories – these are stories at the top of the Product Backlog that are ready to be brought into a sprint but that are not part of the current Sprint Backlog. These are posted on the board so that they are readily available in case the team reaches the sprint goal early and can complete some additional stories in this sprint. Note that these are not called “Stretch Goals”. That term can be perceived negatively by the team, almost as if they are not pushing hard enough in the first place to meet the sprint goal.

Release Burnup – the bigger picture of what the team is working towards. This help avoid the sense of being in an endless churn of sprints with no end in sight.

For teams using Kanban, many elements on this board still apply but may need slight modification. Note the use of colors throughout the board.  It is amazing how teams will adopt color schemes or symbols that communicate the state of their work, highlight important events, serve as key reminders, etc. One type of information not included on the example above is an area for Technical Debt.  Creating an open area on the board for this invites the team members to note it as soon as it becomes apparent to them.  These notes can then be translated into backlog items during grooming. This encourages open discussion about technical debt and surfaces this information rather than just having it in the team members’ heads.

A note for teams that use online/electronic Scrum or Kanban boards: additional information such as the PTO calendar, Impediments and release burnup can be captured in story cards and placed in a column dedicated to that background information. The sprint calendar can be captured by putting Due Dates on each electronic story card. On a physical or electronic board, the story cards can contain as much information as the team finds helpful. Typically the story number, title, and number of story points are included.

Reflections:

  • The Scrum or Kanban board can be used to communicate much more than just the status of the stories and tasks.
  • The information on this board should reflect each team’s personality and process. It will evolve as the team learns.
  • The Scrum Master can help the team during the standup by directing their attention to potential trouble spots on the board.