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, on 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 can 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 | 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. |
| 16 | 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. |
| 17 | (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. |
| 18 | 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.
|
| 19 | 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 | 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. |
Not ranked | ||
| 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) | |
| "spill over" | SCRUM ONLY It is advised to:
| |
| 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). | |
| 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. | |
| 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 are:
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. | |
| Sprint goal | SCRUM ONLY When planning a sprint, | |
| SLA | ||
| Working agreement cross train | ||
| Stakeholder input | ||
| Stakeholder presence | ||
| Roadmap / quarterly planning | ||
| Project approval | ||
| 100 |
Overview
Content Tools