Kickoff Meeting Template #138

Closed
thisandagain opened this Issue Dec 12, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@thisandagain
Contributor

thisandagain commented Dec 12, 2014

Define the deliverables and template for kickoff meetings. First round of notes here: https://etherpad.mozilla.org/kickoff

@thisandagain thisandagain self-assigned this Dec 12, 2014

@thisandagain

This comment has been minimized.

Show comment
Hide comment
@thisandagain

thisandagain Dec 15, 2014

Contributor

What's the scope of this sprint?

Walk through the intake form questions (and in some early cases: fill it out) with the team. Answer questions and try to refine your answers as much as possible. Doing so will help you understand what the scope of this sprint is as well as help folks outside the initiative understand what you are focused on:

What is the problem that we are trying to solve?

*What ails you? 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?

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. The demographics of which are extremely broad and include the UK, Canada, and USA."

What does success look like?

Describe the "state change" that you wish 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?

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. The idea behind this is to set a bar for quality and help us avoid re-inventing the wheel.

What does the MVP look like?

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

What are the risks associated with producing a solution to the problem?

Think short term and long term. What kind of assets will be attached to legacy tools? 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

  • If applicable, the designer (or project driver if no designer is on the team) should lead the group in whiteboarding a solution to the problem.
  • During this process the team should help refine the whiteboard sketches down to something that 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 is 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

Ticketing

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

  • Schedule the daily stand-ups for your initiative
  • Schedule the Monday check-in for your initiative
  • Decide who is responsible for doing the demo at the end of the sprint
  • If you are shipping, schedule a final QA check-in and co-ordinate with devops to prepare for release
Contributor

thisandagain commented Dec 15, 2014

What's the scope of this sprint?

Walk through the intake form questions (and in some early cases: fill it out) with the team. Answer questions and try to refine your answers as much as possible. Doing so will help you understand what the scope of this sprint is as well as help folks outside the initiative understand what you are focused on:

What is the problem that we are trying to solve?

*What ails you? 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?

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. The demographics of which are extremely broad and include the UK, Canada, and USA."

What does success look like?

Describe the "state change" that you wish 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?

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. The idea behind this is to set a bar for quality and help us avoid re-inventing the wheel.

What does the MVP look like?

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

What are the risks associated with producing a solution to the problem?

Think short term and long term. What kind of assets will be attached to legacy tools? 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

  • If applicable, the designer (or project driver if no designer is on the team) should lead the group in whiteboarding a solution to the problem.
  • During this process the team should help refine the whiteboard sketches down to something that 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 is 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

Ticketing

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

  • Schedule the daily stand-ups for your initiative
  • Schedule the Monday check-in for your initiative
  • Decide who is responsible for doing the demo at the end of the sprint
  • If you are shipping, schedule a final QA check-in and co-ordinate with devops to prepare for release
@thisandagain

This comment has been minimized.

Show comment
Hide comment
@thisandagain

thisandagain Dec 18, 2014

Contributor

For product handbook: @secretrobotron @OpenMatt

Contributor

thisandagain commented Dec 18, 2014

For product handbook: @secretrobotron @OpenMatt

@thisandagain thisandagain removed the dec12 label Dec 18, 2014

@iamjessklein

This comment has been minimized.

Show comment
Hide comment

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment