Agile scrum development meetings - all you need to know and more

3 min read. In this series of blog posts we are looking at how to best structure a software development team. In part 1 we looked at the process of delivering software and in part 2 we discussed the typical roles and responsibilities of a development team. Here in part 3 we review the key meetings that take place in an agile development process and how to make them more efficient.

Fluent is a software development agency based in Cambridge, UK. We are a team of designers, developers and project managers building software, apps and websites. Our thoughts are our own and reflect the lessons learnt from over 10 years of delivering software.

Why meetings matter

One of the quickest ways to increase development throughput and velocity is to make meetings more efficient. Meetings should add value to the development process, not frustrate it.

We believe meetings should only involve the essential team members who really need to be there. This is where we don’t agree with the pure agile mantra which wants to involve everyone in everything, be comfortable with that and trust other team members to do their bit.

Key to successful meetings:

• Appoint a chair of the meeting
• Organise well in advance and keep them regular
• Define an agenda and stick to it
• Document and share

If you are unsure of the terms used to describe roles or stages in the process, brush up using our previous project management blog posts.

So here is our list of the suggested meetings required to run a successful development team.

Backlog refinement meeting

Although not a recognised agile meeting as such, this prep meeting can help the others run much more smoothly. Product backlogs are often a dumping ground for ideas and can quickly become unmanageable. Therefore it is time well spent reviewing the backlog periodically with key team members. The main objective is to ensure that when it comes to sprint planning, the backlog of tasks to review is relevant, up to date, prioritised and detailed enough to quickly and efficiently plan a sprint.

Who

• Scrum Master (Chair)
• Product Owner
• Technical Lead
• UX / Designer*

* Involve someone with a design hat as early on as possible, even if the backlog is mostly dev work, there will always be some element of UX / design and it is best to consider this now, rather than mid sprint.

What

• Prioritise the backlog based on current business requirements
• Ensure the work in the backlog is sufficiently defined to estimate
• Remove any user stories that are no longer required

When

• Every two weeks
• More than 2 days in advance of the Sprint Planning meeting

Sprint planning meeting

The key agile meeting. This is where your development team will look at the neatly prioritised and well defined backlog and estimate cases before compiling them into a sprint of work.

Who

• Scrum Master (Chair)
• Product Owner
• Technical Lead
• Developer(s)
• UX / designer(s)

What

• Product Manager describes the highest priority work to be developed
• Developers forge an understanding of what is required
• Estimate enough cases to fill the team's anticipated capacity

When

• After the backlog refinement meeting
• Before the end of a current sprint

Stand up meeting

Essential for day to day communication, the stand up meeting gives the team an opportunity to discuss progress and roadblocks so that everyone is on the same page.

Who

• Scrum Master (Chair)
• Developer(s)

What

• Each team member discusses the work from the previous day and what they intend to do today
• The Scrum Master notes any blockers to take offline

When

• Daily, ideally early in the day
• A brief (15min max) meeting

Sprint review meeting

The big reveal, a chance for the team to present what they have done in the sprint. Be prepared and plan well in advance to make sure the demo goes as smoothly as possible.

Who

• Scrum Master (Chair)
• Product Owner
• Technical Lead
• Developer(s)
• UX / designer(s)
• Other key stakeholders

What

• Developers demonstrate the work completed in the sprint
• Product Managers sign off the work as complete

When

• After the sprint has finished
• Before the next sprint has started
• Typically 1 - 2 hours

Sprint retrospective meeting

While the sprint review looks at what was built, the retrospective focuses more on how it was built and reviews the process from the point of view of all involved. The aim is to find what worked well in the previous sprint and where processes can be improved next time. It is worth gathering feedback in writing anonymously beforehand to get a real picture of how the sprint went.

Who

• Scrum Master (Chair)
• Product Owner
• Technical Lead
• Developer(s)
• UX / designer(s)

What

• Understand what worked well in the process
• Identify what can be improved in the next sprinT

When

• After the sprint review
• Before the next sprint has started

So remember, keep your meetings short, relevant and regular and you'll soon benefit from a more efficient development process.

If you would like any further information on the topics discussed here or in any of our other blog posts, please contact us.

Want more tips on digital product development from people at the cutting edge? Follow Fluent on LinkedIn and keep learning