Support/Kitsune/Roadmap-Process

This document describes the process of making changes to Kitsune, be it in code or in any other way. It's based on a discussion that produced a flipchart diagram: Media:Roadmap-process.jpg, see the digitized version here.

1. Define the problem

If you have an idea, talk to the person who is the champion for a certain part of Kitsune and any other potential stakeholders and decide how to continue:

• Write down a problem statement or a user story on an etherpad (template)
• Talk to and get buy-in from champion and stakeholders (anyone)
• Decide whether to solve it by code changes or without SUMOdev involvement (champion).

2. Involve product manager or development lead

Once you have an idea of what you want and have buy-in from the champion and stake holders get in touch with the product manager or development lead for an initial discussion. Both have the bigger picture in mind and can give you additional information about other ongoing projects your idea might affect, and help answering essential questions. At this stage the problem statement should be turned into a user story, if it hasn't been already. Ideally it is possible to express that as: "I as a (user role) want (function) so that (some value is created)".

• Talk to product manager or development lead about the idea (champion, stakeholders).
• Write down the problem statement as a user story using an etherpad if not done already.
• Add needed additional details to etherpad.

3. Meet with developers

If you need to talk to developers to further explore an idea, to get estimates about potential costs, etc, add your user story to the "needs discussion" document, link to its etherpad and give a heads-up to the product manager. Developers will gather once a week for this "story time" to talk about the ideas listed on that page. With some information upfront they can come to the discussion prepared. The story time is time boxed.

• Add your user story to the "needs discussion" document and give a heads-up to pm (champion).
• Attend the weekly "story time" meeting, if your story is discussed (champion).

4. Make decision

After talking to developers we'll have a problem statement, potential solutions, and cost estimates for those. Now is the time to decide how to proceed. Either by dropping the idea, proceeding by changes that don't need code, by modifying the idea, or by deciding that the solution makes sense and is needed. Changes that affect an area need the buy-in of the champion and code changes require additional buy-in from the product manager.

• Make a decision on whether to proceed with the code changes (champion and stakeholders).
• If the decision is yes: File tracker bug

5. Prioritization

Once the decision is made to include the feature on the Kitsune roadmap the product manager prioritizes it relative to the other items on the roadmap for big ticket items or the backlog for smaller items according to the criteria displayed here and in coordination with the champion for the area. Twice per quarter the team gets together to discuss the roadmap and whether it still reflects the needs of the team.

• product manager prioritizes stories relative to other items on the roadmap or backlog.

6. Implementation

The further out stories that are on the Kitsune roadmap the less detailed they are. As they come closer the PM works with the UX designer, devs and champion to specify them in detail, and to break them up into smaller stories that are fed into the sprints as individual tasks.

• Specify stories regarding requirements and UX
• Break stories down into smaller parts
• Feed them into individual sprints