top of page

Half Time on the Sprint Line

Updated: Jul 29, 2022

The good, the bad and the scientific research. How to motivate your team at the halfway point.

Daniel H. Pink talks in detail about ‘midpoints’ in his book ‘When”. A ‘midpoint’ is the point of which you are halfway through an allocation of time. This is somewhat obvious, but the scientific research behind it is what’s interesting.

Connie Gersick performed a study on human evolution within the workplace, specifically project based roles. And rather than evolving over time to become more effective at adapting in their surroundings, the teams became inconsistent. Gersick noticed that each group showed what she called “formed, maintained and changed”. In the early stages of the project the teams would slowly progress (formed → maintained), then when it came to a midway point their pace changed depending on if they were on-time, ahead or behind plan, known as “sudden transition”.

Jonah Berger also looked at this within Basketball leagues and found that when a team was 1 point behind their opponent they had 58% chance of winning that game, which gave them a higher percentage of winning than if they were up by 2 points.

So how can we use this research to coach agile teams to get a homerun in every sprint?

Let’s look at it in the 3 stages:

Halftime Lag

As ScrumMaster’s we’ve all seen this, but what could in mean?

  1. Forming teams may be getting to grips with understanding how much they can deliver and the teams dynamics

  2. User stories have not been broken sufficiently

  3. Pressure from management to just get it done

  4. Every man for himself rather than a team collaboration towards their common goal

As a ScrumMaster it’s important to recognise yourself but also nurture and guide the team to recognise this themself, you may want to ask some guiding questions:

  1. Is it possible to break this user story down?

  2. Looking at our recent velocity, are we setting ourselves to success?

So what do we, ScrumMasters and teams, do then at this point? It’s time to be that coach at the halftime. I call this the 3 R’s.




Remind the team of the sprint goal. Let the Product Owner inspire the team with the vision: this is why we are here, this is why we care!

Reset the mindset. Why do we deliver in increments, what value does this add?

Re-energise the team by guiding them to realise all the achievements so far. Try a mini retro, everyone throws a ‘what we’ve done well’ in the bucket! It’s been challenging but we are half way through, you have the skills, ability and collaborationto do this. Get back on the court and let’s show them how it’s done!

The answers need to come from within the team.

Halftime On-time

This is a pretty good looking board, is it realistic? In well developed teams, I’d say yes. The key call outs here are, heavy ‘Code Reviews’ and ‘QA in Progress’. What could that mean?

  1. ‘Code Reviews’ and ‘QA in Progress’ aren’t being picked up by the team

  2. Nearing the end, bugs and errors could be found

  3. The sprint may fail or potentially over-worked teams

If this occurs on a regular basis, it’s an area of focus that a ScrumMaster should realise and coach the team in realise this too.

Halftime on-time can be a dangerous place to be. Just as described in both Gersick’s & Berger research if your slightly behind you have 58% more chance in winning the overall match.

Use this to reflect at the halfway point. Yes we are looking good, but what about those guiding questions?

  1. How can we be successful?

  2. What might be the potential bottlenecks?

  3. Where’s the team’s focus in the next half of the sprint?

  4. How can we fine tune and adjust the efforts that we see so that we deliver what we have committed to?

As at that ‘halfway Ontime’ point there is a risk of relaxing the progress and loosing the sprint. Again, use the 3 R’s: Remind, Reset, Re-energise.

Halftime Hit

Wow, the team are as surprised as you! They are smashing it! Needless to say what stands out here are:

  1. ‘Code Reviews’ and ‘QA in Progress’ aren’t being picked up by the team

  2. Nearing the end of the sprint bugs, errors will be found

  3. The sprint has potential to fail

An Agile mindset is not about clearing the ‘Not Started and In Progress’ columns, it’s about producing a potential shippable product at the end of the sprint. If new features are not reviewed and tested, they should not be released into the live environment. Whether or not that live environment is a product or a systems feature.

Value added increments are only add value when complete, not before.

So ScrumMasters, stay tuned to your team, notice patterns, and bring a positive vibe at halftime.

Next time on Maykit Projects blog, we’ll be looking at ‘why agile practices fail’…

Check out our website for more on what we do here at Maykit!

1 view0 comments

Recent Posts

See All
bottom of page