(WIP) Project Management Process document #131
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,168 @@ | ||
| # IPFS Project Management Process | ||
|
|
||
| **Status: work in progress, not even a full draft yet** | ||
|
|
||
| ## Introduction | ||
| TODO: describe the purpose of this document | ||
|
|
||
| ## Table on Contents | ||
| - [Projects](#projects) | ||
| - [Roles](#roles) | ||
| - [Product Owners](#product-owners) | ||
| - [Project Leads](#project-leads) | ||
| - [Project Managers](#project-managers) | ||
| - [Structure](#structure) | ||
| - [Overview](#overview) | ||
| - [Goals](#goals) | ||
| - [Backlog](#backlog) | ||
| - [Milestones](#milestones) | ||
| - [Project Roadmap](#project-roadmap) | ||
| - [Organization Roadmap](#organization-roadmap) | ||
| - [Flow](#flow) | ||
| - [Quarterly Planning](#quarterly-planning) | ||
| - [Software Development Pipeline](#software-development-pipeline) | ||
| - [Implementation](#implementation) | ||
|
|
||
| ## Projects | ||
| TODO | ||
|
|
||
| ## Roles | ||
| TODO | ||
|
|
||
| ### Product Owners | ||
| TODO | ||
|
|
||
| ### Project Leads | ||
| TODO | ||
|
|
||
| ### Project Managers | ||
| TODO | ||
|
|
||
|
There was a problem hiding this comment. We should also add the roles from the current README. In particular, I'm curious how the sprint administrator will change (me). |
||
| ## Structure | ||
|
|
||
| ### Overview | ||
| The project information across the organization is tracked with the structure described in this chapter. At the highest level, we have an Organization Roadmap, which lists all projects and their milestones. Each project contains a set of milestone and milestones contain one or more goals. Goals are the basic unit of work and they describe everything from bugs and new features to general tasks. Goals are collected and tracked in a Backlog. | ||
|
There was a problem hiding this comment. Backlog nominally refers to things which aren't prioritized (in my opinion). Here, it seems to just be used for anything not currently in development. Is this right? There was a problem hiding this comment. It also has a strong negative connotation: "I have a huge backlog". Just want to note that. There was a problem hiding this comment. Backlog is the "place" where all goals are collected in. If a goal is being worked on, it's still in the backlog. I think technically "done" goals can also be in the backlog (just that there's no point of having them there). My previous comment re. standard terminology also applies here. |
||
|
|
||
| ``` | ||
| Organization | Project 1 Project 2 | ||
| | | ||
| Roadmap | Roadmap Roadmap | ||
| | | ||
| Milestones | Milestone 1 Milestone A | ||
| Milestone 1 | Goal 1 Goal A | ||
| Milestone 2 | Goal 2 Milestone B | ||
| Milestone 3 | Goal 3 Goal B | ||
| Milestone A | Milestone 2 Goal C | ||
| Milestone B | Goal 4 Goal D | ||
| Milestone C | Milestone 3 | ||
| | Goal 5 | ||
| Projects | | ||
| Project 1 | Backlog Backlog | ||
| Project 2 | Goal 1 Goal A | ||
| Project 3 | Goal 2 Goal B | ||
| | Goal 3 Goal C | ||
| | Goal 4 Goal D | ||
| | Goal 5 | ||
| ``` | ||
|
There was a problem hiding this comment. I don't understand this chart. Where is Project 3? Why is there a mixture of numbers and letters? Why are milestones under the Roadmap, and under projects - shouldn't they just be under projects? Can goals be in multiple milestones? There was a problem hiding this comment.
There was a problem hiding this comment.
My questions aren't so much "I don't understand" as they are "This is confusing and may confuse people, we should adjust it accordingly." Laying out your points in the text would help. There was a problem hiding this comment. My original goal for this graph was to show how the information hierarchy works between projects and organization and how the organization derives its roadmap from the projects, not necessarily "belongs to" or "is in 1" relationship. Fail, obviously. I'll try to improve this, thinking of lines and arrows or an explanation text to describe what you see in the graph. Suggestions appreciated! As for milestones vs. goals:
I would say no. A goal should only be in one milestone. If there are cases where a goal would belong to two milestones, then that goal should be broken down. I can't think of a case where you would need a goal in two milestones at the same time, any examples you can give?
Not sure which part you mean. Can you provide an alternative text? |
||
|
|
||
| ### Goals | ||
| At the heart of each project are the goals. They are the basic unit of work. Goals can be anything that ***adds value to a release***. This includes issues reported by users, feature requests, bugs, Pull-Requests, general tasks such as refactoring, documentation or research. Goals are collected, maintained and tracked in the backlog by the project lead. | ||
|
|
||
| A goal description includes the following: | ||
| - Name / Summary | ||
| - Describes what the goal is on high level | ||
| - Example 1: "Reduce the size of the go-ipfs executable" | ||
| - Example 2: "js-ipfs should have API Documentation" | ||
|
There was a problem hiding this comment. These are worded very differently. We should have a section about actionably wording names. There was a problem hiding this comment. NB: I'm not sure if this is injecting too much of my methodology here, but I would push back against these issues if they were in my repo so I'm skeptical of using them as examples here. I recommend changing the examples to read more like this: Example 1: "Reduce the size of the go-ipfs executable to 850kb or less" This is because with the current wording you could satisfy both of these goals by doing something trivial. They aren't adequately clear about the work that needs to be done or how you will test whether it has been done. FWIW, this article, The Definition of Ready in Scrum, frames a big part of how I tend to think about whether a ticket/goal is adequately framed and ready to work on (they must be clear, testable and feasible). Is that too Scrum-specific? There was a problem hiding this comment. 👍 to @flyingzumwalt's comments. would love to make our goal titles clear, testable, and feasible. There was a problem hiding this comment. 👍 to have goals with clear ways to assess their completion. |
||
| - TODO: what is a good name for a goal? | ||
| - Description | ||
| - What the problem is and how this goal solves it | ||
|
There was a problem hiding this comment. I usually emphasize that the description should tell you how you will know that the problem has been solved or the goal has been achieved. The description should give enough info to finish the statement "You will know this is done when..." Related: it's important to emphasize that goals should always have a clear completion state. Example: "Better test coverage" and "Improve UX" are bad goals. There was a problem hiding this comment. 👍 yeah +1 for making the goals result-oriented and properly actionable. |
||
| - Type | ||
| - Describe the type of this goal: is it a bug? a new feature? something else? | ||
|
There was a problem hiding this comment. i'd be wary of introducing types as a construct. i think just leave it out. Issues will have different "types", "tags", "labels" and that will be clear/implicit in the descriptions. removing the notion from this model will simplify the model without losing anything ("type" does not get used anywhere else in this document) |
||
| - Status | ||
| - What is the current status of this goal. Is it to-be-reviewed? In progress? Blocked? Done? | ||
|
There was a problem hiding this comment. Okay, so this seems to be where the "stages of the kanban pipeline" get introduced. Please be explicit here that these are mutually exclusive states: an issue can only be one of "in progress", "blocked", "done". Also, express ALL the states, and define clear way to decide what state an issue belongs to. Basically:
There was a problem hiding this comment. I'm hesitant to lockdown the pipeline stages. While we provide an overall, "start here", stages, in reality they may be different for different projects (software vs. spec projects, blog vs. go-ipfs). While most projects' workflow can use simplified stages (as above), some might have extra steps, like "QA" or "Sign off" which can be logical parts of some projects. I'd like to leave that to individual projects to decide. The important part is the structuring of information into the work units described here and using a "pipeline" as a pipeline (ie. stages are the "flow" of work specific to the process of the particular project) |
||
| - Dependencies (where applicable) | ||
|
There was a problem hiding this comment.
|
||
| - Priority (optional, priority can be defined in the backlog) | ||
|
There was a problem hiding this comment.
There was a problem hiding this comment. Removed priority, what you say above makes sense. Waffle allows priority, drag & drop the cards vertically in a column. |
||
| - Any additional information that helps to reach this goal (optional) | ||
|
|
||
| TODO: a clear example | ||
|
|
||
| ### Backlog | ||
| Backlog is the collection of all goals in a project. It should be as comprehensive as possible, including everything that needs to happen or should happen in a particular project. The backlog indicates priority by order: the items that have the highest priority are at the top of the list. The backlog is owned and maintained by the project lead. As part of daily work, the backlog gets updated and a general grooming should happen on weekly basis. | ||
|
There was a problem hiding this comment. What's the difference between daily work updating, and general grooming? There was a problem hiding this comment. In my head the difference is that daily work usually involves a particular set of goals that are being actively worked on --> more attention, daily grooming. General grooming == goals that are not being worked on actively but still need attention (eg. preparing goals to be ready to be worked on, updating their status as discussions evolve, etc.). Or changing goal priorities is grooming work that falls outside the "daily work". Does that make sense? There was a problem hiding this comment. From my perspective (and what I typically do and apparently similar to @haadcode's version) it is:
|
||
|
|
||
| A backlog has the following information: | ||
| - All goals of a project | ||
| - Priority of goals in sorted order | ||
|
|
||
| While the backlog is usually one big list of goals, it may sometimes become convoluted. In this case, the backlog list can be split in two: Backlog and Icebox. The icebox section lists goals that will probably not be worked on anytime soon, or are not ready to be worked on yet, whereas the backlog itself contains the goals that are ready or "approved". If split, together they are called "the backlog" and icebox is referenced only in its specific meaning. The split and maintenance of both lists are done the project lead. | ||
|
There was a problem hiding this comment. +1 for the icebox. It's super useful. We used to call ours "future work" just to be sassy. There was a problem hiding this comment. +1 for "future work". icebox sounds like "ehhh dont do this. boring. not useful enough. yeah maybe, but probably never.". i always felt bad putting things into "icebox". "future work" sounds much, much better to me. There was a problem hiding this comment. I think we should differentiate "future work" and "backlog" much more explicitly. meaning, "future work" is not part of the backlog. There's three things here:
Let's pick a name for both. I think it's typical to call (2.) Backlog in board. but because (1) and (2) were differentiated from (3) (which was historically called Backlog) there's confusion. I would be in favor of calling (2.) "Ready", which make it very clear that they're ready to go. "backlog" is a more apt name for (2 U 3) i think. There was a problem hiding this comment. I tried to break this down more in the latest revision. Still not sure what would be the best way. "Future Work" is definitely better than "Icebox". I think "Ready" is more a state than a description of "where is it listed". Then again, "Ready" + "Future Work" == "Backlog" makes sense... There was a problem hiding this comment. Added this to the document. An example pipeline could look something like this: There was a problem hiding this comment. Updated: _An example pipeline could have the following stages:_
|
||
|
|
||
| ### Milestones | ||
| A milestone is a group of project's goals. Each project has a set of milestones. A milestone is completed when all goals associated with it have been completed. Milestones are tracked in the project roadmap by the project lead. | ||
|
There was a problem hiding this comment. can we define something more clear for what makes a milestone? maybe something along the lines of:
or maybe it's a combination of these? i'm not sure. but being clear here will help us make sure we all agree on how to "milestone" the roadmap. In fact perhaps a more actionable approach is to say:
Perhaps this, but im not sure i agree with it fully:
There was a problem hiding this comment. Updated the document and tried to summarize the important parts. See if it's better now. |
||
|
|
||
| A milestone has the following information: | ||
| - Name | ||
| - TODO: describe what is a good name, give an example | ||
| - Due date | ||
|
There was a problem hiding this comment. always a due date? I think we should motivate Due Dates more seriously, with something external. Basically:
IDK, due dates can be hard. If we do them, we HAVE TO make them count, commit to them seriously, follow them strictly, and adjust them as necessary. Due dates absolutely suck if they start slipping. they become useless, induce guilt without a sense of actionability, and reflect poorly on the team. There was a problem hiding this comment. Changed "Deadline", it being optional. |
||
| - List of goals attached to it | ||
| - Progress indicator | ||
|
There was a problem hiding this comment. In cases where a milestone needs a bit of description, or links to related docs, does this go into an optional description section in the milestone or does it go somewhere else? There was a problem hiding this comment. Does the Progess Indicator really belong in the model specifically? The progress indicator seems to be just (# of Goals done / # of Goals total). This can likely be measured similarly within a Goal (as Goals will likely have subparts, though not significant enough to track in this model). There was a problem hiding this comment. I would like to see a progress information tied to each milestone. Without it, there's no real way to track the status on higher level as it would be either "done" or "not done". I would like to be able to look at a project and answer the questions "how far are we from completion?" as there's a big difference between 2 / 10 and 9 / 10 goals completed. Perhaps it could be described as "Status" instead of "Progress indicator"? |
||
|
|
||
| The Project Lead keeps current milestones up to date on weekly-basis. New milestones should be generated and old milestones updated before the quarterly planning meeting. Prepare new milestones in good time before quarterly planning. | ||
|
|
||
| TODO: a clear example | ||
|
|
||
| ### Project Roadmap | ||
| The milestones are tracked in project's roadmap. The project lead owns the roadmap and is responsible for generating, updating and tracking the milestones. To make sure the roadmap is up to date, the project lead should go through the current milestones on weekly basis. | ||
|
There was a problem hiding this comment. Where do Releases fit? Are Releases tracked as Milestones or do they get separate treatment? There was a problem hiding this comment. I'm not sure, but:
|
||
|
|
||
| The Roadmap Document contains the following information: | ||
| - List of current milestones | ||
| - Ordered by expected due date, next upcoming milestone at the top | ||
| - Current status of the project, ie. milestone progress | ||
| - List of previous, recent milestones (< 6 months) | ||
| - List of links to very old milestones (> 6 months) | ||
|
There was a problem hiding this comment. i'd say leave them there until it's a problem. we can change this when we need to prune documents because they're too big. |
||
|
|
||
| The roadmap can be a high-level overview of milestones and project's progress, so details suchs as list of goals per milestone can be omitted. However, if omitted, the roadmap must contain links to the detailed break down. | ||
|
There was a problem hiding this comment. +1. i would like it to be possible to generate (with a tool) a listing of milestones, goals, and "milestones and goals". eg This could output markdown. :) We just need to way to identify milestones and its component goals. There was a problem hiding this comment. Agreed! A tool to automate all of this would be amazing. Something where you specify which repos are "a project" and it'll generate roadmaps (md files perhaps?) and all based on the issues in the repos. Also, updates and sync milestones, labels, documents and whatnot across the project's repos. Or perhaps it has a dashboard that generates all that information in real-time! |
||
|
|
||
| Examples: | ||
| - [js-ipfs roadmap](https://github.com/ipfs/js-ipfs/blob/master/ROADMAP.md#ipfs-javascript-implementation-roadmap) | ||
| - [Orbit roadmap](https://github.com/haadcode/orbit/blob/master/ROADMAP.md#orbit---roadmap) | ||
|
|
||
|
|
||
| ### Organization Roadmap | ||
| An overview of all projects across the organization is tracked in organization's roadmap. This is similar to a project roadmap, but collects all milestones from all projects into one place. | ||
|
|
||
| Organization roadmap contains the following information: | ||
| - List of all projects | ||
| - List of all current milestones and their progress in each project | ||
| - List of links to old milestones | ||
|
|
||
| The organization roadmap is owned by project management and project managers are responsible for generating and keeping the roadmap up to date. The roadmap should be updated in the quarterly planning meeting as old milestones are reviewed and the project leads commit to new milestones. | ||
|
|
||
| TODO: a clear example | ||
|
|
||
| ## Flow | ||
|
|
||
| ### Quarterly Planning | ||
| TODO | ||
|
|
||
| What: | ||
| - Identify project’s / company’s needs and main efforts. | ||
|
There was a problem hiding this comment. It's important to acknowledge that for projects that have community contributors, quarterly planning is a community wide process. We need to allocate time & process to do quarterly planing for both internal/company roadmap and community-wide project roadmaps. There was a problem hiding this comment. Please just remove reference to "company". say "Organization", as "The IPFS Project" or "IPFS Team/Community" is an organization. even though it does not yet have legal standing. (and it will eventually :) ) |
||
| - Commit to efforts and goals. | ||
| - Produce a high level overview of a roadmap. | ||
|
|
||
| Who: Product Owners, Project Leads, Project Managers | ||
| How often: Every 3 months | ||
| Output: Organization Roadmap (responsible: PM) | ||
|
|
||
| ### Software Development Pipeline | ||
| TODO | ||
|
|
||
| - From Backlog to Release | ||
| - Workflow steps | ||
| - Releasing new versions | ||
| - Keeping the backlog up to date | ||
| - Keeping everyone updated | ||
| - Tracking status and current work | ||
| - Using a signaling board (Kanban) | ||
| - Working towards milestones | ||
| - "Sprint" meetings | ||
|
|
||
| ## Implementation | ||
| TODO | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm interested in knowing what goes here. A item list of the things you want to describe would be good enough to start
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having thought about this, I would actually leave out the Product Owners part (not used anywhere else in the document and can be different per project, and as an organization, who's a product owner and who's not?).
Perhaps leave out the project managers part, too as this would be more an individual roles on the participating organizations. Or should we try to describe the roles of project managers?