Focussed sprints: tricks and tips for better Scrum software development

Author: Lionel Le Boiteux

The end of sprint demo isn’t just a meeting, it’s an opportunity to motivate and focus a team from the beginning of a sprint to the end.

Each of the ‘ceremonies’ that make up the Scrum methodology, from backlog refinement to daily stand-up meetings, has a purpose – but some are more obvious than others.

The stand-up meeting is the easiest to grasp and execute; it’s a quick catch-up that synchronises the team at the beginning of each day and its structure and purpose are obvious immediately, even to spectators with no experience of Scrum.

The end-of-sprint demo might seem equally obvious but in my experience its true value is easily underestimated.

At first glance the end-of-sprint demo looks like an exercise in showing stakeholders how the team has spent the last two weeks and reassuring them that everyone is still working towards an awesome product. At the end of a demo everybody feels good about themselves and the team is ready to loop the loop one more time by embarking on a new sprint!

I think there is more to gain from the demo. Too often it’s an afterthought and the team end up asking: “What should we do for the demo?” on the morning of the demo.

Some would say fail to prepare and you prepare to fail! For me preparation for the demo starts before the Sprint even begins. 

The Start Line

During backlog refinement I like to ask a simple question of each item under consideration; “How are we going to demo this?”. If there isn’t a natural answer then we’ve learned something important about our choice of Epic or Story; the end-user benefits aren’t clear and a review is needed.

After the backlog refinement, and before the sprint starts, comes sprint planning.

With a close eye on its various priorities the team should endeavour to pick two or three themes and group the Epics and Stories associated with them together in a Sprint.

At this stage the team is treading a fine line between staying focussed in one area and having everyone stepping on each other’s toes. In my experience a Scrum team with a good tech lead will self-organise, tackling the stories in the most favourable order and ensuring everyone’s toes are safe and secure!

On Your Marks

One of the great benefits of Scrum is that it prizes real things – real features, real demos and real progress – over opinions about “how things are going”. There is no hiding place and the Scrum team know that they will stand or fall by what happens at the demo.

To get the most of the demo you need to get the right mix of people to attend. It’s one thing to show your work to your Product Owner but quite another to demo it to the Product Director, Finance Director or CTO.

At Intelligent Environments we also work collaboratively with development teams from our customers so in some cases team members will also find themselves demonstrating to people in matching roles from a customer’s organisation.

Getting the attendees right is critical if you want to capture good feedback but it can also give the Scrum team an extra incentive to make sure that their stories are perfectly defined and understood. 

Get Set

With everyone clear about the benefits of the stories and how the demo is expected to go, it is time to throw down the gauntlet!

We send our demo invitations before we’ve written a line of code and we explain exactly what stakeholders will see and who will be showing it to them.

For example, a typical invite might say “In this sprint we will focus our effort on the registration page. At the demo: John will present you the new registration page layout based on the results of the user-testing sessions, Sophie will demonstrate the new address lookup functionality powered by service that Pat would have built and integrated to the app and Simon will show you the performance to improvements made by changing the way we download the image.”

When the invite is sent, the expectation is set and there is nowhere to hide. It is time to deliver! 

Go!

By the time the sprint starts the team has a clear objective and I can assure you that our demonstrators John, Sophie, Pat and Simon will pay considerable attention at the stand-ups to ensure their share of the demo is being worked on.  No one wants to stand in front of their peers and managers with nothing to show for the last couple of weeks.

Conversely, delivering on our promises, week after week, gives the team a great sense of achievement and instils real confidence in the stakeholders. For the person presenting on the day there’s nothing better than when the boss’ boss’ boss smiles and says “Good job!”.

That’s the kind of motivation I want for my team.

The Finish Line

Employing these little tricks – asking up front how a story can be demonstrated, focussing on a few themes and demoing to a demanding audience – will ensure that everyone is engaged during your backlog refinement, planning sessions and sprints.

By using these consistently, sprint after sprint, project after project, the quality of a team’s delivery is improved along with the confidence, motivation and enjoyment of everyone in it.

Enjoyed this? More reading:

UX Evolution: next-gen design for financial services

Software Development: Choosing the best tools for the job 

29 Jul 2016

Author: Lionel Le Boiteux

The end of sprint demo isn’t just a meeting, it’s an opportunity to motivate and focus a team from the beginning of a sprint to the end.

Each of the ‘ceremonies’ that make up the Scrum methodology, from backlog refinement to daily stand-up meetings, has a purpose – but some are more obvious than others.

The stand-up meeting is the easiest to grasp and execute; it’s a quick catch-up that synchronises the team at the beginning of each day and its structure and purpose are obvious immediately, even to spectators with no experience of Scrum.

The end-of-sprint demo might seem equally obvious but in my experience its true value is easily underestimated.

At first glance the end-of-sprint demo looks like an exercise in showing stakeholders how the team has spent the last two weeks and reassuring them that everyone is still working towards an awesome product. At the end of a demo everybody feels good about themselves and the team is ready to loop the loop one more time by embarking on a new sprint!

I think there is more to gain from the demo. Too often it’s an afterthought and the team end up asking: “What should we do for the demo?” on the morning of the demo.

Some would say fail to prepare and you prepare to fail! For me preparation for the demo starts before the Sprint even begins. 

The Start Line

During backlog refinement I like to ask a simple question of each item under consideration; “How are we going to demo this?”. If there isn’t a natural answer then we’ve learned something important about our choice of Epic or Story; the end-user benefits aren’t clear and a review is needed.

After the backlog refinement, and before the sprint starts, comes sprint planning.

With a close eye on its various priorities the team should endeavour to pick two or three themes and group the Epics and Stories associated with them together in a Sprint.

At this stage the team is treading a fine line between staying focussed in one area and having everyone stepping on each other’s toes. In my experience a Scrum team with a good tech lead will self-organise, tackling the stories in the most favourable order and ensuring everyone’s toes are safe and secure!

On Your Marks

One of the great benefits of Scrum is that it prizes real things – real features, real demos and real progress – over opinions about “how things are going”. There is no hiding place and the Scrum team know that they will stand or fall by what happens at the demo.

To get the most of the demo you need to get the right mix of people to attend. It’s one thing to show your work to your Product Owner but quite another to demo it to the Product Director, Finance Director or CTO.

At Intelligent Environments we also work collaboratively with development teams from our customers so in some cases team members will also find themselves demonstrating to people in matching roles from a customer’s organisation.

Getting the attendees right is critical if you want to capture good feedback but it can also give the Scrum team an extra incentive to make sure that their stories are perfectly defined and understood. 

Get Set

With everyone clear about the benefits of the stories and how the demo is expected to go, it is time to throw down the gauntlet!

We send our demo invitations before we’ve written a line of code and we explain exactly what stakeholders will see and who will be showing it to them.

For example, a typical invite might say “In this sprint we will focus our effort on the registration page. At the demo: John will present you the new registration page layout based on the results of the user-testing sessions, Sophie will demonstrate the new address lookup functionality powered by service that Pat would have built and integrated to the app and Simon will show you the performance to improvements made by changing the way we download the image.”

When the invite is sent, the expectation is set and there is nowhere to hide. It is time to deliver! 

Go!

By the time the sprint starts the team has a clear objective and I can assure you that our demonstrators John, Sophie, Pat and Simon will pay considerable attention at the stand-ups to ensure their share of the demo is being worked on.  No one wants to stand in front of their peers and managers with nothing to show for the last couple of weeks.

Conversely, delivering on our promises, week after week, gives the team a great sense of achievement and instils real confidence in the stakeholders. For the person presenting on the day there’s nothing better than when the boss’ boss’ boss smiles and says “Good job!”.

That’s the kind of motivation I want for my team.

The Finish Line

Employing these little tricks – asking up front how a story can be demonstrated, focussing on a few themes and demoing to a demanding audience – will ensure that everyone is engaged during your backlog refinement, planning sessions and sprints.

By using these consistently, sprint after sprint, project after project, the quality of a team’s delivery is improved along with the confidence, motivation and enjoyment of everyone in it.

Enjoyed this? More reading:

UX Evolution: next-gen design for financial services

Software Development: Choosing the best tools for the job