Skip to content

Latest commit

 

History

History
61 lines (47 loc) · 5.24 KB

kickoffs.md

File metadata and controls

61 lines (47 loc) · 5.24 KB
Raw

Project Kick-Off Meetings

Summary

  • Good kick-off meetings are essential. Over-communicate, plan and ticket at the start of the process. This will save you time and headaches later. Kick-offs are the booster rocket that propels you through the entire sprint.
  • Get all the stakeholders together. To make sure everyone's on the same page at the start of the project. One meeting with all the stakeholders is exponentially better than a jillion one-on-one meetings. (Note: MoFo's often this mistake. Round them all up! Do it!)
  • Do some visual thinking. Get out your pens. Draw stuff. Add sketches to the planning ticket. Images can work wonders for people's understanding.
  • Take as long as needed. Don't try to cram a kick-off into a half-hour if it needs longer; the time spent here will pay dividends later.
  • TOP TIP: Make sure all the individual tasks and deliverables are ticketed and assigned. The Planning ticket is a good high-level summary ("Make soup.") But the art is in dividing up and assigning the individual tasks with the group ("Buy carrots," "steam vegetables," "blend," "heat", "serve.")
  • ** Everyone should have clear to do's and next steps when they leave the meeting**. Don't punt. Leave the meeting clear on roles and next steps.

##Kick-Off Meeting Checklist

SCOPE: What's the scope of this sprint?

Walk through the intake form questions with the team. Make sure they're clear and well filled out. Answer questions and try to refine your answers as much as possible. This will help you understand the scope of this sprint, and help folks outside the initiative understand what you are focused on.

PROBLEM / GOAL: What's the problem we're trying to solve?

**What's the opportunity? What's broken? What's missing? ** What would be cool? Is this a long running problem? Have we tried to solve this in the past and failed? Who is already working on the problem? Did this problem come from user research?

AUDIENCE: Who is this for?

Visitors, learners, mentors, teachers, partners, staff, community? Describe the user or users that you are trying to impact. Example: "The mass of visitors to BBC web properties. There are roughly X million visitors to BBC web properties. Their demographics are extremely broad and include the UK, Canada, and USA."

SUCCESS: What does success look like?

Describe the "state change" you're trying to accomplish. How will we know if we've succeeded or failed? Do we have metrics that we can reference? How does that state change relate to our core values?

BENCHMARKS: What are some benchmarks for a solution?

Has anyone else solved this problem (inside or outside of Mozilla)? If applicable, share URLs, organizations, or other services as benchmarks. That way we can set a bar for quality and avoid re-inventing the wheel.

MVP: What does the Minimum Viable Product look like?

What's the bare-bones set-up that solves the problem? Think about the most important part of the solution -- the most impactful part. What's the smallest thing we can do to start to make that state change happen?

RISKS: What are the risks associated with producing a solution?

Think short term and long term. How much time will be needed to maintain what we make? How much money will it cost? Is it resource-intensive? Any hard partnerships, commitments, or events that depend on the solution?

Whiteboard

  • Do some whiteboarding and visual thinking. Break out of the box of etherpads and words and blah blah blah.
  • If applicable, the designer (or project driver if no designer is on the team) can lead the group in whiteboarding a solution to the problem.
  • During this process, the team should help refine the whiteboard sketches down to something the team feel comfortable committing to for this sprint. It's great to have a long-term vision for how you want to evolve something -- but what's important in the kickoff is to focus on what you can ship in two weeks.
  • Photograph and attach the whiteboard drawings to the planning ticket

Ticket

  • Based on what you are trying to accomplish, break the sprint into discrete issues in GitHub.
  • The Planning Ticket is the high-level meta ticket. But you'll probably need to break the project intp small pieces and file those tasks as separate tickets elsewhere.

Accountability

  • Go through each ticket and assign them as a group
  • If issues are left unassigned, review them with the team and decide to either punt them from the scope of work, or find an owner
  • Issues that don't have an owner and/or are "nice to haves" may be good for contributors. Identify these issues and make sure that they have good quality documentation.

Follow-up

  • Stand-ups. Schedule the daily stand-ups for your initiative. ("P1" projects typically have daily 15-minute stand-ups to ensure questions get answered fast.)
  • **Demos.**Decide who is responsible for doing the demo at the end of the sprint
  • QA. If you are shipping, schedule a final QA check-in and co-ordinate with devops to prepare for release