This page covers how teams can complete the Intake milestone.
Learn More About Intake
Intake happens every project phase. The intake milestone is an important foundation builder for teams. They get together, define common goals, build trust, and set expectations in working together.
Before you proceed with this page, learn about the project components, include the agile lifecycle:
Setting Key Performance Indicators (KPI's) of Success
It’s not enough to just perform agile product development work. How will a team know they have hit their mark? How will they know they have progressed in solving problems? The answer to this lies in Success measurements. Success measurements (otherwise known as Key Performance Indicators) are measurements that can be can be defined in a lot of ways. They relate to the problems that businesses focus on solving in a given release, and outline the steps for teams to measure their progress when they change and deliver results. This workshop outlines a framework for defining key performance indicators and measurements of success based on business goals and user audience pain points today.
The client intake workshop helps new teams onboard to new phases. Project representatives and the client enter basic details about the project, the purpose, the current problems, and thoughts about the priorities for the upcoming phase.
Cross-functional Agile teams are like heist crews: people who get together work towards shared outcomes together and do not stick to only one isolated set of responsibilities. Every time the team plans work, they agree together about who owns what, and who wants to collaborate with whom. This happens every work iteration. When you first get together as a new team, each person should identify the desires they are interested in participating and owning for teamwork. You as a self-organized team need to have the power to change this for each person. This allows people to explore new duties they have never done before. The team needs to support people doing work for the first time as Agile teams support each others’ growth together.
Working agreements are an Agile deliverable that act as a set of guidelines and expectations established by a team or group to govern how they will work together effectively. The team changes them as their team matures over time. Working agreements are commonly used in various contexts, including Agile and Scrum development teams, but they can be applied to any group or project where people need to work together cohesively. Working agreements help cross-functional Agile teams develop their own principles of self-organization. There are multiple working agreements across different areas on teams. Each team defines their own working agreements, so they are unique per team because they are made by teammates themselves. The working agreements change whenever the team takes a retrospective on work and agrees to change the way they work.
You may think that someone dictates how a team should work in Agile. After all, we have all of the rules written in Scrum, right? Don't all Agile teams operate the same? They tell us what meetings to do, when to do them, and how to do them. This is a misconception. Agile teams govern themselves and own their own process together. Everyone on the team, even the interns, even the apprentices, should have a say in how they work together. This is a principle called self-organization, and it's crucial to build on Agile teams. In order for them to do their best work, they must be handed the keys to ownership of the process. A team process looks different on every team. At its core, it's a summarized agreement for how a team wants to work across functions to get work done. The process is visualized in a flow chart so that everyone can understand how work gets done. When the team takes retrospectives and discusses how to change their process with working agreements, they should update this team process flow chart to ensure it's accurately depicting how the team operates.
A Project Plan outlines each week of work that all team roles are doing, or planning on doing. A sprint team shouldn’t plan everything up front, but rather guess at what’s coming in the later weeks and adjust every week.
Every cross-functional Agile team gets together to decide how they deliver value every sprint. This workshop enables teams to break down their cross-functional work based on the shared outcomes that the project needs to achieve. The team takes the goals and deliverables for a project and determines the 11 week plan based on different functions on the team to make the project a success. In the industry, this deliverable is called a Sprint Plan. In this workshop we call it a Project Plan. It’s maintained every sprint and teams typically plan 2 to 3 sprints ahead so that they can forecast and plan ahead.
Sprint Goals are created every sprint before the sprint begins. Teams get together and review their plans to outline the outcomes they want to achieve. Then they break down the outcomes into steps to complete and considerations. The people on the team commit themselves to the work so that they can determine themselves how they want to be involved: responsible, accountable, consulted, or informed.
