DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Conducting Sprint Retrospective Meetings
  • Test Automation and User Story Done Criteria
  • Can the Agile Method Be Scientifically Proven?
  • Agile Scrum and Infrastructure

Trending

  • Best Practices for Developing Cloud Applications
  • Distributed Tracing Best Practices
  • A Better Web3 Experience: Account Abstraction From Flow (Part 1)
  • Monetizing APIs: Accelerate Growth and Relieve Strain on Your Engineers
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Scrum Retrospective 2 — Gather Data

Scrum Retrospective 2 — Gather Data

Who has the data? One of the Scrum Master's roles in the retrospective is gathering and presenting objective data for the team to review.

Herbi Bodner user avatar by
Herbi Bodner
·
Jul. 30, 18 · Presentation
Like (1)
Save
Tweet
Share
7.47K Views

Join the DZone community and get the full member experience.

Join For Free

This is the second post of my blog post series about the five phases of a Scrum Retrospective. In this post, I cover the most crucial ideas for Stage 2 — Gather Data.

If you haven't read the previous post in this series you can find it here: Stage 1 — Setting the stage.

These five stages are presented in the book Agile Retrospectives — Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

Ok, let's get to the meat.

The goal in this phase is to bring the facts of the sprint to the table, so that every participant has the same picture of what happened during the iteration.

I usually split this phase up in two steps. First, I announce the hard facts and statistics based on the data the team generated during the sprint. Secondly, we want to get the insights and personal opinions from each individual to generate a complete picture.

Step 1: Hard Facts

The idea of this step is to make the status quo transparent, based on the facts you already have. This type of data is usually generated during the sprint and does not reflect any personal opinions, but hard facts.

It is the responsibility of the Scrum Master to get this information before the meeting starts. Even though the Scrum Master doesn't have to get the data by himself, he is responsible to make sure the data will be available for the meeting.

This data includes the sprint goal and the amount of planned and delivered story points. Next to that, it also includes any other hard facts, which are measured during the sprint.

Sprint Goal

First of all, I name the sprint goal and we figure out whether we achieved our plans. Most of the time, it is obvious whether or not we made the sprint goal, but sometimes there is a short discussion within the team. This is fine, because I want a collaborative decision if we did or did not make it.

I use this information also to keep track of how the team is doing over time. And you can mention in the retrospective that the team achieved the sprint goal, for instance, 5 times in a row.

Story Points

I mention how many story points we initially planned for the sprint and how many were successfully finished.

Here it is a good idea to have an Excel sheet with historical data prepared and show in a graphical overview how the team is doing over time. Keeping this historical data in a diagram can give you insights easily in how the team grows over time, is more productive, finishes more work, etc.

Other Measured Data

You can mention at this point any other important data, which has been measured during the sprint.

For instance, if your team struggles with too many open bugs and too little of them are solved and closed during the sprints, then this is important data to keep track of. This data is usually available easily by having a look at the bug-tracking tool you are using.

In such a case you can announce the amount of open bugs before and after the sprint.

If your team has constantly problems with the high amount of incidents during the sprint, which prevents the team from making good progress with the planned user stories, then this is also important data to keep track of. This data is also usually available in a bug-tracking tool and you can bring this data to the group here as well.

Basically any interesting data, which is measured and might be important to the team, is welcome at this point to share with everyone. This is because it helps that everybody has the same picture of what happened during the sprint.

Data You Don't Want to Show

But there is also some type of data which you don't want to show to the team. This is any kind of data, which might put a specific person on the spot — unless you specifically intend to do so.

For instance, showing how many story points were delivered by each person brings the lowest-scoring person in an uncomfortable situation and doesn't help the team. Therefore, this should be avoided.

You should also make sure to just bring data which has been measured and therefore is a fact. Don't bring data, which you think is a fact, but actually is just your personal opinion.

For instance, if you know that people didn't do as much pair programming as initially planned, but you didn't measure how often they actually worked together in pairs, then don't mention it at this stage.

At this point it is important to just give the hard facts, which have been measured, to the team so that everyone knows what was going on in the sprint.

Step 2: Personal Opinions from Each Individual

When the hard facts are on the table, the second step in the Gather Data phase is to collect the personal opinions and feelings of each individual.

Here it is important that everyone has a voice. Therefore I always use a format, which gives each individual some time to think on his own and express his or her own opinion.

Silent Writing

In order to achieve this I always use a couple of minutes of silent writing, where each person writes down the items on sticky notes so everyone has to think about his or her own experience, feelings and events during the sprint.

If you don't use sticky notes, but just start a discussion where everyone shares his or her thoughts, then you usually end up with a very unbalanced set of data. Because more confident people will take over the floor and express their opinions while other participants won't be able to contribute their thoughts.

Especially if there are a few introverts in the team, these people are not going to speak up while, for example, the senior developer taking over the floor. Even though the opinion of the introverts might be very valuable, they won't have the chance to contribute them to the discussion.

Therefore, for the gather data step I always use a format, which starts with a few minutes of silent writing followed by a round of explanation, where each person explains his or her stickies to the group.

Formats for the Gather Data Step

There are many different formats for the gather data step out there, which basically all work the same way with just slight differences in asking the questions. For instance, there is the Start Stop Continue format, or the Mad Glad Sad retrospective, or you can use the Sailing Boat.

Some of these formats work better than others in different situations. For instance, if the sprint went really well and there is almost nothing to complain, then the Start Stop Continue retrospective is a good way to generate some ideas for improvements.

If you use the Mad Glad Sad retrospective to gather data when a sprint worked really well, then it will basically work, but in my experience, you will get much better results using the Start Stop Continue format. If you want to know more about that check out my post about the Start Stop Continue retrospective.

Recap

Ok, let's quickly recap the important things of the Gather Data phase.

The goal of this phase is to bring all relevant data to the table so that every participant has the same information about the sprint.

This data consists of the hard facts, which have been measured during the sprint. These are the Sprint goal, the amount of planned and delivered story points and any other relevant facts, which have been measured.

The second step is to get the opinions and feelings from each individual by a few minutes of silent writing. After that each individual presents them to the team and clarifies what he/she means.

At that point you have all the important data ready and can continue with the next phase, which is Phase 3 — Generate Insights.

I cover the details about Phase 3 in my next post of this series, which I am going to publish in about 1 week. So stay tuned and keep an eye on the blog.

Meanwhile, I would be interested in formats you mostly use to Gather Data in your Scrum retrospective. Leave a comment if you have any interesting insights, which formats work well in specific situations!

Ok, that's it for now. See ya in a bit, and HabbediEhre!

Data (computing) scrum retrospective agile Sprint (software development) Database

Published at DZone with permission of Herbi Bodner, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Conducting Sprint Retrospective Meetings
  • Test Automation and User Story Done Criteria
  • Can the Agile Method Be Scientifically Proven?
  • Agile Scrum and Infrastructure

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: