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.
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.
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 | 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. |
| 9 | Testing | Make conscious choices about Testing, and store those in your Definition of Done. Who will do it, according to which input or method, how will the results be shared, and how will rework be handled? |
| 10 | 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. |
| 11 | 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. |
| 12 | 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. |
| 13 | 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. |
| 14 | 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) |
| 15 | Clear description | A good description should describe a challenge and ask for a solution (it should not ask for a 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? |
| 16 | SMART | 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. |
| 17 | Validation | |
| 18 | Peer review | |
| 19 | (Sprint) Planning | |
| 20 | Metrics: Predictability or Cumulative Flow | |
| Story points | ||
| "spill over" | ||
| Business value | ||
| Pre-refinement | ||
| Demo | ||
| Sprint goal | ||
| SLA | ||
| Working agreement cross train | ||
| Stakeholder input | ||
| Stakeholder presence | ||
| Roadmap / quarterly planning | ||
| Project approval | ||
| 100 |
Overview
Content Tools