We recently started the development on a new project.

We kicked of with part of the team with a sprint zero including mostly technical setup and some clarification of interfaces. Now we will be finishing our sprint 1. This is the first sprint we did in our new team configuration and with actual implementation. Yay!🎉

I am now preparing the retrospecitve and wondering:

What are good points to look for when preparing the first retro for a new team configuration?

Should I chose a retrospective format that is especially helpful to promote:

  • team building?
  • understanding of the vision / mission of our project?
  • tackling of the first few impediments we encountered?
  • something completely different that would be best to strenghten early on?

None of us is new to scrum but we just started working together in this particular team-configuration.

3 Answers 3


congratulations on your first sprint :)

As you pointed out the team is still forming so there will be lots to talk about and having a structured approach is going to be helpful as it sets up good behaviours.

I would recommend the following questions: -

  • What helped the sprint ?
  • what slowed down the sprint ?
  • What was fun ?
  • what could impact the next sprint ?

Send out the question prior to the retro, as you might not know how people will engage in the meeting, and it gives people time to think. Ideally this would be a shared document or workspace depending on the tools you are using.

During the meeting, give people time to add more comments to a shared area. Then go through the feedback during the retro, one by one.

The comments in "what helped" and "what was fun" will be things you want to maintain, these may be things that feed into your delivery processes or a team ways or working document or wiki page. "what was fun" will also start to give you an idea of what everyone enjoys so that you can play to people's strengths.

"what slowed down the sprint" will be things you will want to either get sorted as a scrum master or keep an eye on recurring. Try to identify 1 thing to change, add it to the backlog as a story for the next sprint. You will also want to review these in the next retro.

Finally, discuss, summarise and capture comments "what could impact the next sprint" for use during your next sprint planning.

Remember, not everyone will have feedback and that is OK, to encourage psychological safety within the team don't force people to contribute.

  • Hi Jack Leon, thanks for your helpful answer. So to summarize you would especially for the first retro recommend two things: To have a structured approach as its sets up good behaviours and to take care that everyone can contribute in the retro and feels safe to do so. Does this catch the essence correctly?
    – Kaadzia
    Commented Jul 18, 2022 at 8:26
  • 1
    Hey, almost :) Yes I would recommend a structured approach. A couple of key things are 1. Try to take an action away from the retro and put it in the backlog so that the retros are tangibly useful in enhancing your working environment. 2. Allow people NOT to contribute if they don't want to so that they feel safe to so when they want to and feedback is genuine.
    – Jack Leon
    Commented Jul 18, 2022 at 12:15

The Sprint Retrospective Isn't for SM- or PO-Driven Agendas

It doesn't really matter if this is "Sprint Zero" or your ten-thousandth Sprint. The objective of the Sprint Retrospective remains the same:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored.

Because the retrospective is really the key to the inspect-and-adapt process of your Scrum implementation, and targets continuous improvement, there are a couple of things I would say about your underlying question.

  1. You as the (presumptive) Scrum Master should not be driving the content of the retrospective, except perhaps as a member of the Scrum Team who identifies ways to improve the Sprint Retrospective if the team lacks the initiative or experience to use it effectively. In other words, facilitate but don't drive the event, and use it as an opportunity to work with the Product Owner to add Scrum or Sprint Retrospective training to the Product Backlog if the team will need to consume capacity to make better use of the event in future.

  2. As a member of the Scrum Team, the Product Owner should be encouraged to participate in identifying what went well and what didn't, too. This shouldn't cross the line into criticizing the Developers or the Increment, but the continuous improvement process includes the whole Scrum Team, not just the Developers!

  3. None of the other things you mentioned in your list are things that should be done within the Sprint Retrospective. The outcomes from the retrospective should be identification of "impactful improvements," not the detailed planning of them. The guide specificially says:

    The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

So, while the process is new, and the Scrum Team may not have yet gelled, it would be inappropriate to set a rigid agenda or use the event for "work" that properly belongs in a different event or on one of the backlogs.

An Example Technique to Kick-Start a Retrospective

There are certainly some common techniques for soliciting feedback during a retrospective. One such is throwing up a bite of pasteboard with two columns, one of which is labeled "Do More of These Things" and the other labeled "Do Less of These Things." Then hand out some sticky notes, and let people write out a few notes and slap them on the board in the appropriate column. As with planning poker, the goal here is to kick-start a discussion or identify common themes without anchoring.

There are other techniques, and Scrum is not at all prescriptive about how you implement the event. All the framework really requires is that you use the event for its intended purpose, and that purpose is primarily about continuous improvement through inspection and adaptation. Notably, the guide says:

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

There are a number of books on the topic of running effective Sprint Retrospectives, some written by well-respected Scrum Trainers and thought leaders. However, the good ones all focus on how to use the event to empower the team and help it be more self-driving; any book that advocates a rigid agenda or anything firmer than some gentle "safety bumpers" to help a new team increase their process maturity shouldn't make your reading list for this important event.

The Last Responsible Moment for Inspect-and-Adapt Within the Current Sprint

The Sprint Retrospective is the last responsible moment for inspection-and-adaptation of the current iteration. Following the retrospective, your next event is Sprint Planning, so this is the opportunity for the team to reflect on what was learned about its process during the current Sprint, and creating some action items for experimentation or evaluation in a future Sprint. It isn't the only time this can be done; it's just the last time it can be done within the current Sprint, so try to keep the focus on things that weren't already identified earlier in the Sprint.

  • Hi Todd, thanks for your detailed answer. So, do I get this right, your answer to my question "What are good points to look for when preparing the first retro for a new team constellation?" would be: "Do not treat the first retro any differently than all retros, that are going to follow. Do not try to drive the content of the event and choose any format, that focuses on empowering the team and help it to be more self-driven " ?
    – Kaadzia
    Commented Jul 18, 2022 at 7:54
  • @Kaadzia Aside from not knowing what you mean by "constellation,", I'd say that's a pretty good summation of what I said.
    – Todd A. Jacobs
    Commented Jul 18, 2022 at 13:23

An interesting retro format early on in a project is the pre-mortem.

You ask the team to list all the things that could go wrong with the project, then you have a think about ways to mitigate the risks.

  • 1
    Thanks Barnaby :-) We went with a different approach for our first retro (and learned a lot about what went well and what we can improve :-) ) But the pre-mortem sounds very good. We will probably do that as one of our next retros. Thanks for the suggestion.
    – Kaadzia
    Commented Jul 26, 2022 at 11:42
  • 1
    We did the pre-moprtem retro as well now. We identified plenty of critical points and decided on a few specific tasks we will do to improve. So: A very good retro. (And it was lots of fun, too ;-) ) Thanks for suggesting it, @Barnaby
    – Kaadzia
    Commented Aug 26, 2022 at 6:45
  • Glad it helped! Commented Aug 26, 2022 at 6:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.