Improving your Agile ceremonies

Stay on this page to read the full guide or download it as a PDF for easy access anytime.

About this guide

Team ceremony quality has a huge impact on team morale, spirit and productivity. A team with good quality Agile ceremonies implements the right things, correctly, with few change needs down the road. It is also able to listen to customer and stakeholder feedback and react quickly.

Improving the ceremony practices has high return on the effort invested. But the changes don't appear overnight. The team must improve things slowly and take the new elements of ceremony practice into use and build them into positive habits, if they suit the team.

This guide helps the team and the team coach (usually Scrum Master) accurately evaluate current ceremony practices, and allows them to choose new elements to try to improve team performance.

Who is it for?

This guide is meant for the team coach and team itself to assess the current level of ceremony practices and choose new elements to try. In this sense it acts as a map to higher levels of ceremony practices. The guide is meant for teams that are using either a Scrum or Kanban way of working.

How to use this guide

1. Read the guide completely.

2. Together with the team, assess your current ceremony practices for each of the six ceremonies. Use a workshop or the printable questionnaires at the end of the guide for this.

3. Choose the ceremony in which your team finds most room for improvement.

4. Within the team, discuss elements from the current and next levels of ceremony practice. Choose one, or maximum two, elements for testing in upcoming ceremonies. Use the checklists at the end of this guide for team review of each ceremony.

5. Allow a few times to test the new elements. Then assess if they worked or need adjustment, or if you did not feel they offered benefits. Repeat steps 3–5.

Improvement of the ceremony practice does not need to stop, ever. You can focus more energy on it in the beginning, but a good team never stops seeking ways to improve.

When and how long

Backlog refinement: 1 Hour - Every week at same time.

Sprint planning: 1-3 Hours - First day of sprint.

Daily: Max 15 min - Same time every day – follow up with topical meetings after.

Retrospective: 1 Hour - 2-4 week intervals. Off cycle from sprint ending.

Sprint review: 1-2 Hours - Last day of sprint.

Demo: 30-60 min - Near end of sprint, or when stakeholders are available.

4. Find your level

5. Development path beyond retrospectives

Developing the team

Team development requires management support and a team coach who understands the principles of coaching, and has time and motivation to develop the team to a higher level of performance. The best results always come with a good internal coach. Scrum masters and line managers are suitable roles and positions to be team coaches. The development of ceremonies is a long journey. You will get results fast, but remember: it doesn't stop there.

6. Checklists

6.1 Agile super ceremonies: Backlog refinement

• Regular refinement sessions 2-4 times a month

• Product owner has been selected

• Backlog exists, and some effort to prioritize it has been done

• Backlog items that have been refined and have more than just a title in writing (i.e. at least a simple description)

• Effort estimation is in use

• Refinement focuses on the next sprint only, not beyond that

• Definition of Ready has been defined, and is actively used

• Team discusses and defines customer need or value for each backlog item that is refined

• Acceptance criteria are in active use

• Refinement session has timeboxes per item

• Testability and automatic testing are considered

• Complex items are prepared off-session and presented to the team / studied in take-a-bite manner

• Discussion is active, nobody dominates it, and the discussion is documented to the backlog item

• Team has a size limit for too large stories, and regularly splits stories in refinement session

• Refinement focuses on content for next 1-2 months

• Backlog priorities and trash item cleanup is done regularly

• Forward planning for items that require longer feasibility studies are actively planned

• Active use of the INVEST model for user stories

• Balance between too little – too much detail

• Team actively does rough refinement of future items (beyond 2 months)

• Team considers assumptions and story risk and uncertainty, as well as dependencies to other teams or outside team factors (for example environments)

• Alternative solutions to build are considered

• Common refinement sessions with other teams when doing dependent items

• Advanced item-splitting techniques

• Active development of estimation skills

6.2 Agile super ceremonies: Sprint planning

• Separate sprint planning meeting is held at start of sprint

• Top of the backlog has been pre-prioritized by product owner

• Team selects items from top of the backlog until it feels that enough work has been chosen for sprint

• Team creates tasks for items that it plans to start with

• Team may choose to use stretch goals for sprint

• Definition of Done is written, understood by team, and actively in use

• Only items that pass team Definition of Ready are approved to sprint backlog

• Most items chosen for sprint are pre-refined and pass DoR

• New items that do not pass DoR are refined in the planning meeting until they pass DoR

• Team does a sprint simulation to balance load, plan initial few days

• Team identifies when it has overcommitted in past sprints, and adjusts sprint scope

• Discussion about the chosen content is active, especially about customer need, effort estimation and acceptance criteria

• Team considers capacity spent by not completed items from previous sprint that are decided by team and PO to be continued in this sprint

• Team considers capacity impact of training, holidays, etc.

• Team doesn't approve backlog items larger than team limit to be single sprint backlog items (without splitting)

• Team uses sprint goals

• Items to be potentially demoed at end of sprint are planned in the session

• Items from sprint backlog with high risk and uncertainty are identified

• Team remembers the big picture, product vision, release vision and considers how the chosen work ties into that

• Members volunteer for items that encourage learning new things

• Team finds a timebox for Sprint planning that works best

• Team is able to re-order implementation of sprint backlog items to find best possible way to achieve the sprint goals (and completion of the chosen tasks)

6.3 Agile super ceremonies: Daily

• Daily occurs several times a week and is timeboxed to less than 15 minutes

• What I did yesterday, what I am going to do today, issues

• Daily occurs daily, even when scrum master is not present

• What have I learned that others really should know?

• When is my current task ready for next step?

• Team members really listen to each other

• What is started next? Team considers sprint backlog priorities.

• Usually at least one "ah, good thing we had this meeting" moment

• Frequent follow-up meetings for issues identified in the standup

• Feedback is heard and responded to

• Team has ownership of the daily ceremony (with or without Scrum Master)

• Team considers progress toward sprint goal and sprint backlog completion

• Celebration of achievements

• Team notices when someone is stuck, but is not saying it out loud

• Offers for help are heard and accepted

• Team is cognizant of risks in the sprint backlog items and knows when to act

6.4 Agile Super Ceremonies: Retrospective

• Retrospective is held regularly

• Retro results in some action points

• Action points have a named owner

• Product Owner may participate (but as a normal team member – not a PO role)

• Previous retrospective action points are followed up

• Retrospective action points are loaded to next sprint as sprint backlog items, and treated as any other story chosen for sprint (DoR, refined, effort estimated, tasked)

• Retrospective methods are trialed and changed occasionally

• Different themes or focused topics are used occasionally

• Team understands what kind of things are under its influence, and agrees on actions that it can carry out on its own

• Retrospectives are hosted in a manner that allows focused discussion, root cause analysis and action planning

• Different ceremony practices are improved in focused retrospectives

• Retrospective host is changed occasionally, or hosts are rotated

• Retrospectives are also held together with other teams

• Team finds ways to influence issues that are outside its direct sphere of influence, for example by setting example, building organizational influence by active participation in communities, or by employing chain of command

• Retrospective issues that remain a "constant" but are unpopular in team voting are addressed to solve issues that bother only a few participants

• Team also regularly uses "futurespective" methods such as pre-mortem

6.5 Agile super ceremonies: Sprint review

• Review is separate section or separate meeting from Demo

• Items that are done are closed

• Items that are unfinished are moved to next sprint or back to backlog

• Product owner approves items in review

• Team analyses "Done" items: Did they pass DoD? Did they pass NFRs?

• Do they fulfill the customer need, as understood now? Is anything else needed related to this customer need? (added to backlog)

• Inspect the potentially releasable increment

• Team analyses the unfinished, non-stretch goal items: Why weren't they finished? Blocked or overcommitted?

• Team discusses sprint learnings: Backlog priorities need re-adjusting? New items for backlog or for next sprint content proposal? Some items in backlog are not needed based on learnings for this sprint?

• Product owner can approve work also in mid sprint, not only in review

• Project risks and mitigation action plans are considered

• Project big picture, budget and schedule are reviewed and updated

• Team identifies stakeholders who need additional information about progress, and finds way to get it to them

6.6 Agile Super Ceremonies: Demo

• Demo is a separate section or separate meeting from Sprint review.

• Stakeholders are invited to participate in the demo session

• Demo is not shown from developer machine or branch, but checked in codeline branch

• Demo audience is given opportunity to give feedback

• Demo script is planned beforehand

• Common, easy-to-understand language is used

• Team rotates between different demo presenters: PO, dev, tester, stakeholder, customer support...

• Presentation of how the demoed feature ties into the big picture

• Demo script and item planning is started already in refinement or sprint planning

• Some stakeholder groups get a different demo from others (i.e. business demo once every 1-2 months, sprint demos at end of each sprint)

• Demo leads to discussion or follow-up meetings after feedback; PO documents insights

• APIs are demoed with dev or test tools, that are also available for others

• Customers or stakeholder reps are encouraged to try out the feature themselves

• Separate recordings or demo sessions are arranged for stakeholders who can't join the main session

• Demo session also celebrates work done and achievements. Team feels sense of accomplishment after the demo.

• Stakeholder opinions are not "message from god" but are feedback as any other. Team may choose to not consider these as "the one truth" and can challenge them. Demo is a place for collaboration – not reporting.