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 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
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
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. How we do Sprint Retrospectives

How we do Sprint Retrospectives

Anders Abel user avatar by
Anders Abel
·
Jan. 28, 13 · Interview
Like (0)
Save
Tweet
Share
4.52K Views

Join the DZone community and get the full member experience.

Join For Free
Sprint retrospectives are a key part of Scrum, which goes back to the lean roots of scrum with the focus on continous improvements. When I wrote this series on scrum I unfortunately overlooked the retrospectives, so it’s time for a revisit. To be honest I’ve been sloppy with retrospectives and only started doing them regularly in the second half of the project. That was bad, we missed a lot of possibilities to improve things we were doing wrong in time. We should have started earlier!


Retrospective Goals

The goals of our retrospectives is not only to find areas that have to be improved, but also to make everyone aware of areas that work well. This is important both to make sure that everyone on the team knows what the success factors are – those habits that we should just keep on with and not forget. It also works as a moral booster that we are not only focusing on problems.

We split our retrospectives in four parts:

  1. Group Brainstorming on Areas
  2. Individual Brainstorming
  3. Presentation
  4. Discussion and Action Point Summary


Group Brainstorming on Areas

The first thing we do is to do a group brainstorming on areas. Everyone can come up with suggestion of areas that we should think of and discuss. A typical list from this first phase could look something like this:

  • Requirements
  • Code Reviews
  • Development Environment
  • Sprint Demo


There is no motivation done on the areas suggested, they are just listed as they are mentioned. This phase is typically done in a few minutes.


Individual Brainstorming

The second phase is the individual brainstorming. Everyone grabs a bunch of post it notes and a pen. On each post it note a plus or minus sign is noted together with a short comment.

+ The new deploy routine is really great.

- Sprint Demo was not well prepared. Embarassing in front of customer!

 

There is no limit on what topics can be listed. Everything that is related to the project can (and should!) be mentioned. When out of inspiration for more issues, the list of areas can be consulted, but there is no kind of limitation to only keep to those areas.


Presentation

When everyone has finished writing it’s time for the presentation. Each one on the team presents their post-it notes, putting them up on a whiteboard. Related notes are posted close to each other. Being the last one to present means frantically trying to remember if someone else said something similar and finding that note…

During the presentation there is no discussion, but it’s fine to ask questions for clarification.

- Was it the stuff that we demoed that wasn’t tested enough, or was it the order we demoed the issues in that was bad?


Discussion and Action Point Summary

Finally it’s time for discussion. At this point it is clear where the huge issues are. It’s just to look for clusters of minus-marked notes. Wherever there are several of them that are about the same issue something has to be done.

We pick the most important issues and then sort out what to do about them. Some goes to the team as general advice for the next sprint

Think twice before interrupting a fellow developer with headphones on. Send a mail or Skype message if the possible to avoid interrupting.


Some is added to the backlog

Fix build routine for deploy packages to be possible to do in one step.


Some is added as another point to the definition of done list

Always do a rebuild all and check for warnings before committing.


Some are sent on to the product owner to handle

The shopping basked checkout confirmation by writing a signature with the mouse is really, really awkward to use. Should we really keep it?


Last, but not least we take a look at the list of plus notes and talk a bit about them. Then we leave with the feeling that we’re doing a great job. Next sprint we’ll be even better, it’s time to raise the bar once more to get one step closer to perfection.


Scrum series

  • Scrum for Developers
  • Scrum – Nowhere to Hide
  • Scrum and Project Governance
  • Requirements in Scrum
  • Disarming Different Estimates with a Deck of Cards
  • Test and Verification in Scrum
  • Scrum and the Business Implementation
  • How we do Sprint Retrospectives

retrospective Sprint (software development) scrum

Published at DZone with permission of Anders Abel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Spring Cloud: How To Deal With Microservice Configuration (Part 1)
  • Using the PostgreSQL Pager With MariaDB Xpand
  • PostgreSQL: Bulk Loading Data With Node.js and Sequelize
  • Top Five Tools for AI-based Test Automation

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

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: