Improving your Agile ceremonies

Not in use 

The team runs the risk of accepting backlog items into a sprint backlog with unclear descriptions, leading to slow implementation and more errors and changes later. The backlog will not be prioritized or kept clean of trash stories. Difficult to estimate or prepare for work beyond next sprint.

Basic level

Regular refinement sessions clarify the backlog items. The product owner is better able to prioritize backlog items both in the refinement session and outside it. Refinement actions focus on items in the next sprint and slightly beyond.

Advanced level 

The team actively uses “Definition of Ready”. Size limits are set to guide item splitting. Complex items are identified in the backlog and prepared separately, outside the refinement session. Refinement actions focus on the next 1-2 months of backlog.

Super level 

The backlog cleanup is done regularly. The team actively uses different splitting methods and the INVEST model for user stories. Common refinement sessions with other, dependent, teams are arranged. Refinement actions span beyond the next 1-2 months of backlog, stretching to 12 months as rough refinement.

Not in use 

It is a rare that a Scrum team does not use the sprint planning ceremony. If it doesn’t, that probably means there are no sprints – meaning that the team uses pure Kanban.

Basic level

The product owner brings a proposal of sprint content to the planning meeting, and the top of the product backlog is also prioritized to allow change to this proposal. The team can negotiate and adjust the content of the sprint, depending on velocity. Stretch goals may be in use. Definition of Done is written and in use.

Advanced level 

Sprint goals are defined. “Definition of Ready” is used as a last gatekeeper to accept content into the sprint backlog. The sprint simulation is done to balance load and to sanity-check the sprint content. Customer need, and acceptance criteria are actively discussed for all items.

Super level 

Demo planning is started at sprint planning. High-risk items and items that require mid-sprint direction validation are identified. The big picture and vision is kept in mind during the event.stretching to 12 months as rough refinement.

Not in use 

The team can’t reach sprint goals effectively, and will struggle to implement the most important things from the sprint backlog. Calls or offers for help are often disregarded, and the team members work more in isolation. Self-organized teamwork is difficult.

Basic level

The daily occurs several times a week, and is not longer than 15 minutes. The basic format is: Yesterday, Today, and Impediments.

Advanced level 

The daily is driven by the team itself, not by the Scrum Master. The Scrum Master is an observer. Learnings are shared when needed. People see the end of their current task and discuss optimum next item from the backlog. ”Ah, good thing we had this meeting” moments are common. The daily leads to active helping of other team members.

Super level 

The team has full ownership of the daily, and considers progress toward sprint goals. Items that are done are celebrated! Impediment solving is assisted by the daily and stuck team members are helped even if they did not ask for it.

Not in use 

The team does not learn why certain tasks were and were not completed. The big picture (schedule, deadlines, budget) remains unknown.

Basic level

Task completion is reviewed. Not completed items are moved to the next sprint.

Advanced level 

The product owner approves deliverables. The items that are done are regularly checked against “Definition of Done”. The team analyses why some items were not finished. Sprint learnings and backlog adjustments are done.helping of other team members.

Super level 

The product owner can approve items mid-sprint. The team considers the sprint’s impact on the big picture, and risks and mitigation plans are actively reviewed. Reports to stakeholders are considered.

Not in use 

Improvement of the ways of working is  slow or nonexistent. Team performance is static at a certain level.

Basic level

Regular retrospectives are in use and result in discussion, identification of improvement items, and action points. Action points are assigned an owner.

Advanced level 

Meeting time is managed to allow good root cause analysis and action planning. Previous action points are followed up. Action points may be loaded into the sprint backlog, to give the team ”permission” to work on them immediately. Different retrospective methods are trialed, and vary. Sometimes the retrospective has a specific theme.

Super level 

Retrospectives are used to improve all Agile ceremonies regularly. They don’t always have the same host, and are sometimes held with other teams to improve the program or organizational cooperation. Futurespective methods are used regularly. The team expands its influence beyond team.

Not in use 

Feedback from items is missing, and this can result in changes or reported errors later. Increased risk that the product increment is not being releasable to production. 

Basic level

The demo is a separate session from the sprint review, and regularly gets stakeholders to participate. Feedback is received and reflected in the backlog.

Advanced level 

Different people present demos. Demos are tied to the big picture of the release or product vision. The demo is based on a prepared script, and leads to active discussion.

Super level 

Different methods (different demo sessions, recordings, email, screenshots) are used to maximise feedback. The demo session is also used to celebrate successes and enhance the team’s feeling of achievement.

Advanced level 

• 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

Super level 

• 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 considere
• Common refinement sessions with other teams when doing dependent items
• Advanced item-splitting techniques
• Active development of estimation skills

Advanced level 

• Only items that pass team Definition of Ready are approved to sprint backlog
• Most items chosen for sprint are pre-refined and pass Do
• New items that do not pass DoR are refined in the planning meeting until they 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

Super level 

• 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)

Advanced level 

• 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

Super level 

• 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

Advanced level 

• 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

Super level 

• 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

Advanced level 

• 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 sprinto

Super level 

• 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

Advanced level 

• 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

Super level 

• 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.