What are sprints and stand ups and why do we use them?

At TPXimpact, we work in an agile way. What we mean by this is that we take an iterative approach to developing products. Many of our clients are already working agile so they get how we work and we iterate our approach to align with them. However, we also find ourselves introducing agile to clients who’ve not taken the leap… For those new to this way of working, the names of the ‘ceremonies’ (meetings), let alone the content, can feel a bit odd. We thought we’d outline what they are when they happen, and why we bother with them.

Our meetings usually operate within the cadence of ‘sprints’. A sprint is a set period of time – which can be a week, a fortnight, a month or longer – during which the team adds some value to the product. In a discovery phase, this might be learnings to validate our assumptions. In development, it tends to be new features.

Meetings are opportunities for us to inspect and adapt, i.e. for the client to see what’s going on with the team’s work, and for the team to adapt according to feedback (inspection and adaptation, along with transparency, are the pillars of Scrum). We’ll have a kick-off with clients when we start the project, and then once we begin the regular cadence, these are the meetings you can expect:

Sprint planning

(Also known as sprint kick-off)

When? Start of the sprint.

What? The team looks at the backlog – a list of what tasks need doing – and decides what can be completed in the upcoming sprint and how we’ll do it. We end up with a goal for that sprint that won’t change (although the nature of the work might).

How? This meeting will often be based around a backlog management tool, such as Jira or Trello. If the team is estimating the size of different tasks to see which will fit, they might use story points, T-shirt sizes, or some other approach.

Why? Putting upfront effort into planning the sprint and deciding on a shared goal means that, once it’s started, team members can work without too many interruptions. This makes them more productive, so the client is likely to see benefits more quickly. Running regular sprint planning also increases the predictability of how much can be achieved in a sprint, which helps when reporting expectations for project progress to senior stakeholders. Involving the client-side product owner means that the sprint goal remains in line with organisational priorities.

Stand up

(Also known as daily scrum)

When? Daily, around 15 minutes.

What? The team shares what they have done and what they plan to do, as well as key learnings and blockers.

How? This meeting might just be a conversation, or could also be based on the backlog management tool. Some teams like to use icebreaker questions, too. When colocated, the team will do this meeting standing, hence the name.

Why? This is an opportunity to make sure the team is on the same page, to work out dependencies and avoid duplication, discover blockers to resolve, and continually assess whether what we’re doing is adding value.

Retrospective

When? End of the sprint.

What? The team reflects on the previous sprint – what went well and not so well, and what they want to change about it.

How? Often the meeting will use a retrospective tool. EasyRetro is a favourite as it doesn’t require a download, or Mentimeter allows good interactions. It’s common for teams to use alternative groupings – eg. the ‘Marie Kondo’ retrospective, where you add thoughts under ‘Brings You Joy,' 'Throw Out,' and 'Recycle' – to keep things fresh. It’s important for this session to feel constructive, rather than destructive (there’s a guiding principle for this).

Why? The ultimate inspect-and-adapt opportunity, a retrospective enables us to avoid the definition of insanity according to Einstein: 'doing the same thing over and over again, but expecting different results.' It only works if the actions are implemented, so some teams will assign owners and check in on progress at the next retrospective. Actions may be for the client team, as well as for TPXimpact, and are one way in which the client can use the project as a springboard to improve ways of working in the department or organisation.

Show and tell

(Also known as playback, or sprint review)

When? End of sprint.

What? The team shows the wider stakeholder group what value has been added in that sprint – learnings in discovery, iterations in Alpha and beyond.

How? We aim to show, rather than tell, so in development projects, you will see the prototypes, software or automation in demos. The team may ask questions of stakeholders in attendance, and will certainly invite feedback. For those who can’t attend, we’ll normally send around an update with the slides – either by email or in a public wiki (a web page that people can view and edit) – to provide another opportunity for input from the wider group.

Why? There’s no better way to find out if what we’re building meets expectations than to show you what we’re building. Sharing openly and early avoids us going too far down a path before we know we’re on the right one. This ensures that the client only invests budget and resources in solutions that work for the organisation and other users and stakeholders.

Always adapting

Alongside these regular team meetings, it’s normal for the delivery manager to meet one-on-one with the product owner or senior stakeholder from the client. These sessions focus on the direction of travel for the project against organisational priorities.

The shape of these meetings gives a pretty good sense of how we work — sharing openly and frequently and providing plenty of opportunities for course correction. It helps us ensure that you:

• Know what your supplier is doing, and therefore are not spending money or time on something you don't want.
• Are confident that what the supplier team is doing fits into the bigger picture of your aims and projects.
• Learn from the project for ongoing ways of working and organisational knowledge (ie. you won't lose all the hard-earned knowledge you've gained when the supplier team moves on).

The actual meeting's cadence might differ slightly depending on the engagement, and one of the benefits of agile working is that we can adapt it to work for the outcomes we need. That said, it will always be our role to coach client teams through this adaptation and continuously upskill their teams. All of this goes beyond these meetings, of course - it's part of everything we do.