Improving your Agile ceremonies

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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

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

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.

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.

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

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

• 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

• 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

• 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

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