When you are part of a new agile team, it can be hard to get started and see what to focus on. This simplified model suggests next steps for agile teams at Yamaha. Please realise that these are suggestions, as input for retrospectives or discussions, and organisation specific.
Where to start: read through the steps to understand at which level your team is roughly. Do not skip any steps that your team does not yet meet. That is your "team level".
How to use: consider the next tree steps, and discuss in your team which one makes most sense for your team to try to achieve.
| Level | Step | Details |
|---|---|---|
| 0 | People have been brought together to act as a team. | An agile team is usually larger than 3 people, and smaller than 10 people. Their work is related to the same or related product(s). |
| 1 | Organise a Daily (Scrum). | Plan to meet together Daily: for 15 minutes, at the same time, at the same place, with the full team. Use this time to plan the coming 24 hours of work together. Questions that could be utilised are:
|
| 2 | Visualise work in progress. | Collect all the work that the team is currently working on, and make it visible (either on a physical wall everyone has access to, or in a tool like Jira). An item should at least have a title, an assignee, and a requester. |
| 3 | Close items done with information to requester. | Make sure that any item of work that is completed, is marked as "closed" (on the wall or in the system) and that the person who requested the work is informed, so they can make use of the deliverable. |
| 4 | Visualise work requested. | Collect all the work that is requested from the team nearby the work in progress, to create a Product Backlog. Anyone is allowed to create a Product Backlog Item, but is required to connect with the team to make sure the item is seen & understood. |
| 5 | Appoint a person to prioritise work. | A team has a limited capacity to take up new work, so it is vital to pick up work that is most valuable at a moment. To achieve this, the Product Backlog should be organised with the most valuable items on top. This is done by the "Product Owner" in scrum, and the "Service Delivery Officer" in YME Kanban. |
| 6 | Escalate early. | When you need others who don't respond, when you lack input or system access, immediately share with your team and ask advice how to resolve this. If the problem is related to work, mark it with an impediment (Jira: "add flag with comment"). One person (ideally a scrum master) should take escalations outside of the team, so others can continue to work. |
| 7 | Working agreement (inside team) | Take a moment with all team members to discuss how you want to work together. This could be about when and how to communicate to each other, how we pick up work, how we treat each other, but also for example whether the radio can be on during work hours. Write the agreement down in an easy-to-access location and review it periodically. |
| 8 | Validation | Before closing a product backlog item, we should check with the requester whether the request was fulfilled. Only after confirmation, we close an item. |
| 9 | Definition of done (DOD) | Take a moment together with all team members to discuss what it means exactly when a work item is called "done". For example: has it been tested, documented, validated by the requester, deployed to a production environment? Write the agreement down in an easy-to-access location and review it periodically. |
| 10 | Testing | Make conscious choices about Testing, and store those in your Definition of Done. Who will perform the test, according to which input or method, how will the results be shared, and how will rework be handled? |
| 11 | Peer review | Make conscious choices about Peer Reviews, and store those in your Definition of Done. What is expected as input, what is expected as output, and how will rework be handled? |
| 12 | Organise a periodic retrospective. | Plan to meet together recurringly, ideally each two weeks, to review together how the past period has been and what could be experimented with to make the work run more smoothly, impediments to occur less frequently, and for the team to enjoy work better. Plan a few (1-3) improvement action items to work on together for the coming period, and to review in the next retrospective. |
| 13 | Clear description | A good description should describe a challenge and ask for a solution (it should not define the solution). Ideally a description is a business case: who needs it, which feature do they need, what would they be able to do with it that they currently cannot? |
| 14 | Clear acceptance criteria | A piece of work becomes truly workable when it is specific, measurable, acceptable, result oriented, and time-bound. For us that means we should at least have acceptance criteria that clarify how something will be tested/used. |
| 15 | (Sprint/Kanban) Review | Once your work items have clear exit criteria, you can review together whether these have been met. Has the target been achieved? Then we can celebrate, communicate, and close the item(s). Are there defects or new scope requested? Then discuss how to handle these - before deployment in the same work item (normal procedure for defects and tiny change requests), or in the future in separate work items (normal procedure for larger change requests). |
| 16 | Definition of ready (DOR) | Take a moment together with all team members to discuss when a work item is ready to be picked up. For example: which details do we require as a description? Are there specific fields in a tool that need to be filled? Do we require a screenshot or steps to reproduce an error? Do we need the requester to be available for follow-up questions? Write the agreement down in an easy-to-access location and review it periodically. |
| 17 | Refinement | Meet together periodically with the full team, to check whether remaining work items are understood and meet the DoR. Only items that meet DoR can be picked up to work on. It's possible to add an ad-hoc refinement session when there is no ready work to pick up. |
| 18 | (Sprint/Kanban) Planning | Once you have a DoR and DoD that you actively use, your work should be refined far enough to be able to plan your work.
Most likely the following maturity steps will make your planning easier. |
| 19 | Estimation | In order to learn how much the team can plan in a sprint, or how long it might take for items to come out of a kanban flow, it often helps to estimate items.
|
| 20 | Metrics: Predictability or Cumulative Flow | In order to better understand how we can improve our efficiency or quality, metrics can be used to measure trends. These numbers can be used to investigate why something is the case, and should never be compared by team (a team that delivers more story points than another is not better, only different, for sizing methods will differ).
|
| 20 | Demo | An agile team should give periodic live demo's, because this helps a lot to manage expectations about a project and get true item-level feedback. For a demo session the usual audience consists of:
During the demo new features are shown in a live demo, while research findings are shared in a powerpoint summary. Feedback is sollicited, and any items not yet validated are checked for completion with the PO. The demo is usually part of Sprint Review, at the end of a Sprint; Kanban teams generally have a monthly or bi-weekly demo. |
| 21 | Working agreement cross team | In order to receive items with DOR-required information, it is often needed to make agreements with other teams about the accepted way to request work. A cross-team working agreement can also contain decisions about timing or contact persons - anything that helps makes cross-team communications easier. |
| 22 | Release procedure | Once we have a cross-team working agreement, we can work together on a Release Procedure. Who needs to be informed before/after a release? How will we manage dependencies? Where/who will we document release names & content? (at YME we use Jira Versions & Enable Story for this) |
| 23 | Pre-refinement | When you find that your refinement session lags, and there is a lot of uncertainty about items, then you will likely benefit from having separate pre-refinement sessions. Invite only the PO/SDO to write the item business case and acceptance criteria, as input for the refinement session. |
| 24 | Sprint goal / Kanban team target | When planning a sprint, it helps to focus on a "sprint goal". A sprint goal could be to complete one feature/epic, to resolve bugs after a release, to recude support requests, or any other clear singular goal. Items required to achieve that goal are planned into the sprint first, with potentially other items added as padding. Sprint goal items always get priority over additional items. When working Kannban, it makes sense to focus on a single epic or purpose together with the team. This allows a piece of work to be completed in a shorter period of time than when individuals work on their own targets, and to bring value to the end user more quickly. This is a way to work together inside a team and achieve focussed results within a short period of type. |
| 25 | Business value | One method to understand the benefits an item will bring, is to estimate "business value". Most teams use a Fibonacci range because smaller estimations are more accurate than large ones (1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100). When taking up new work, consider the business value versus the story points: a BV13 SP1 item is low-hanging fruit, while a BV1 SP13 item may not be worth doing (unless it unlocks other work). |
| 26 | SLA | If a team works on production breakages / incidents, it's important to have a Service Level Agreement. An SLA usually answers:
For most companies, these questions differ by Priority of the service requests. YME has an SLA. Is your team contributing to your train SLA? https://support.yamnet.com/projects/SD/reports/sla |
| 27 | Sprint "spill over" / Kanban long-lasting work | Sometimes the work in a sprint does not get completed before the sprint ends. How does your team handle it? Do you have an agreement about it? It is advised to:
Sometimes Kanban work can take more time than estimated, bogging down a team with a single work item that is hard to complete. It is advised to:
|
| 28 | Stakeholder input & presence | |
| 29 | Roadmap / quarterly planning | |
| 30 | Project approval | |
| 100 |
Overview
Content Tools