Planning Process Reboot
3 views
Skip to first unread message
Rob LaRubbio
May 1, 2012, 7:54:17 PM5/1/12
to motech-ar...@googlegroups.com
I've shared this with a couple of people and gathered some feedback
on it. I'd love to get feedback from the larger group and then
start to move forward with the change. So if you could review it
and respond with any additional thoughts or questions I would
appreciate it.
Some of the feedback has been incorporated below. Other outstanding questions include:
This process is heavily influenced by the process at UserVoice:
http://www.uservoice.com/blog/founders/trello-google-docs-product-management/
The goal is a simple process with a regular cadence that is transparent to developers, the public and project stakeholders. It is meant to provide an organizing structure for the work, but not manage developers work. Additionally it is meant to show what is being worked on, what is coming up in the queue and approximately when it will be completed. It is not intended to provide accurate release dates for features or produce development velocities.
Cards
A card represents a unit of work. It could range in size from a large feature such as OSGi, technical debt or refactoring work or a simple bug fix. Cards should be labeled so at a glance their type (feature, refactor, bug) can known. Feature cards should contain a link to a spec, bug cards should contain a link to the bug on google code.
Card Templates
Feature
Short description
Link to Spec
Link to or name of code branch
Link to Code Review (Gerrit or similar hosted tool)
Refactoring
Description of current code
Explanation of issue
Description of refactoring/architecture change
Link to or name of code branch
Link to Code Review
Bug
Link to google issue
Steps to reproduce
Description of expected outcome
Description of actual outcome
Link to or name of code branch
Link to Code Review
Boards:
Inbox
Ideas
- An idea should at a minimum be a 1 to 2 sentence description of a feature or enhancement.
Modules
- A card represents a module that is being submitted for inclusion into the platform
- The card should contain a pointer to the source location, a link to the spec for the module and a discussion of any non-generic code within the module
Roadmap
- This has all the major projects for each quarter looking roughly 3 quarters ahead. These big projects are moved to the Planning board once that quarter begins.
Bugs
Inbox
- unvetted reported bugs. Bugs can be entered directly on this list, or on the google code issues. If a bug originated on google code the card should contain a link to it.
Needs input
- We’ve had issues reproducing the issue and the original reporter needs to provide more info.
Accepted
- Yes, this is almost most certainly a bug.
Planning
Next Up
- This is a roughly prioritized list of the next projects we want to spec out for development
Spec
- This means “someone needs to write a spec”. The card at this point is usually just a rough idea.
- Specs should be written in a publicly accesible location and linked to from the card. (Google docs)
Ready
- We have spec that’s been reviewed by a project stakeholder or the dev team.
- We may have a wireframe or other needed artifacts.
- The card is now ready to be reviewed in a planning meeting and either moved to the Current Development board or sent back to Spec for refinment.
Current Development
Next Up
- Prioritized list of all cards vetted and ready for design & development.
- It’s worth noting that as a engineer or designer you’re not required to take the top card off the stack but rather the top card you feel most apt to handle.
In Progress
- These are the cards that are under active design or development.
- Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
- All development should be done on a branch
Review Queue
- These are the cards that have development (included any local team QA) complete and are waiting on a code review and later merge to master
- Review should be done by a different organization from the developing organization
- Review should check both code style and quality as well as adherence to the spec
- Additionally Review should verify any dependent documentation has been updated.
- Merge to master should be done by the reviewer once approved.
- If the review is not approved notes should be added to the card and it should be moved back to In Progress
Release #
- These cards have been merged from a feature branch to master and accepted in a review
- Once a platform release is created a new Release list should be created for the next release
Meetings & Regular Communication:
In general I'd like as few meetings as possible. I'd also love as much asynchronous communication as possible (email, irc, etc.)
Monday Summary Mail
What was completed last week with avatars/names or who completed it, etc.
Tech Call (30 - 60 mins)
This is an as needed call when face to face agreement or discussion is needed. Probably won’t have it or won’t have it often.
Inbox Review Meeting (30 mins)
Mandatory Attendees: Rob, John
Optional Attendees: anyone who wants to attend or present an idea from the Inbox
If you submitted a card to Inbox board, in either the Inbox or Module column, you are expected to attend this meeting and introduce the story behind the card. The goal is to help the rest of the team understand the associated use cases and pain points.
The key to keeping this meeting focused: solutions are not discussed, only problems.
Product Planning Meeting (1 hr)
Attendees: Rob, John, Vivek, Sanchit, Bruce, Jakob
The goal of this meeting is to review all cards from the Planning and Engineering boards ready to move to the “Next Up” column on the Current Development board. For each card we move we’ll make sure there are no outstanding questions or concerns and we may discuss what the next step is (ex: do we need to build a prototype first?). Once all the “ready” cards are moved to Next Up we’ll re-sort the entire Next Up queue according to priority (yes, even cards that were at the top of the list last week may now be moved to the bottom).
We’ll also assign a level of effort estimate to each card. We measure the effort in terms of easy (1 star), medium (2 stars), hard (3 stars). This estimate is based on previous experience (as a company, not individuals): have we done anything similar before, how familiar are we with this domain, do we have any in-house experts, etc. We’ll use the cards to give engineers a sense of how much work is behind this card and also we use it as a signal to the rest of the team how big of a deal a card is (during the product meeting) and to celebrate progress.
Finally we’ll review all the bug cards. If a card doesn’t have enough info or if it’s going to take significant development time (more than a few hours) we won’t move it to “Next Up”. All cards we do move to “Next Up” go to the top of the queue before everything else. Above all else we want to make sure we’re always fixing what’s broken first.
Standup (10 mins)
Teams are free to host their own stand ups, but no MOTECH wide standup will be held. Teams should get in the habit of sharing any interesting information, blocking issues or questions that come up on the mailing list.
Some of the feedback has been incorporated below. Other outstanding questions include:
- Do we need the architecture list or can we combine it with the dev list?
- Where should specs live? (Google Docs, Google Code wiki, Trello card)? (My vote is Google Doc)
- Should we use Google Code Issues or are the boards enough?
- Who will write the specs?
- Must the review be done by a different org.?
This process is heavily influenced by the process at UserVoice:
http://www.uservoice.com/blog/founders/trello-google-docs-product-management/
The goal is a simple process with a regular cadence that is transparent to developers, the public and project stakeholders. It is meant to provide an organizing structure for the work, but not manage developers work. Additionally it is meant to show what is being worked on, what is coming up in the queue and approximately when it will be completed. It is not intended to provide accurate release dates for features or produce development velocities.
Cards
A card represents a unit of work. It could range in size from a large feature such as OSGi, technical debt or refactoring work or a simple bug fix. Cards should be labeled so at a glance their type (feature, refactor, bug) can known. Feature cards should contain a link to a spec, bug cards should contain a link to the bug on google code.
Card Templates
Feature
Short description
Link to Spec
Link to or name of code branch
Link to Code Review (Gerrit or similar hosted tool)
Refactoring
Description of current code
Explanation of issue
Description of refactoring/architecture change
Link to or name of code branch
Link to Code Review
Bug
Link to google issue
Steps to reproduce
Description of expected outcome
Description of actual outcome
Link to or name of code branch
Link to Code Review
Boards:
Inbox
Ideas
- An idea should at a minimum be a 1 to 2 sentence description of a feature or enhancement.
Modules
- A card represents a module that is being submitted for inclusion into the platform
- The card should contain a pointer to the source location, a link to the spec for the module and a discussion of any non-generic code within the module
Roadmap
- This has all the major projects for each quarter looking roughly 3 quarters ahead. These big projects are moved to the Planning board once that quarter begins.
Bugs
Inbox
- unvetted reported bugs. Bugs can be entered directly on this list, or on the google code issues. If a bug originated on google code the card should contain a link to it.
Needs input
- We’ve had issues reproducing the issue and the original reporter needs to provide more info.
Accepted
- Yes, this is almost most certainly a bug.
Planning
Next Up
- This is a roughly prioritized list of the next projects we want to spec out for development
Spec
- This means “someone needs to write a spec”. The card at this point is usually just a rough idea.
- Specs should be written in a publicly accesible location and linked to from the card. (Google docs)
Ready
- We have spec that’s been reviewed by a project stakeholder or the dev team.
- We may have a wireframe or other needed artifacts.
- The card is now ready to be reviewed in a planning meeting and either moved to the Current Development board or sent back to Spec for refinment.
Current Development
Next Up
- Prioritized list of all cards vetted and ready for design & development.
- It’s worth noting that as a engineer or designer you’re not required to take the top card off the stack but rather the top card you feel most apt to handle.
In Progress
- These are the cards that are under active design or development.
- Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
- All development should be done on a branch
Review Queue
- These are the cards that have development (included any local team QA) complete and are waiting on a code review and later merge to master
- Review should be done by a different organization from the developing organization
- Review should check both code style and quality as well as adherence to the spec
- Additionally Review should verify any dependent documentation has been updated.
- Merge to master should be done by the reviewer once approved.
- If the review is not approved notes should be added to the card and it should be moved back to In Progress
Release #
- These cards have been merged from a feature branch to master and accepted in a review
- Once a platform release is created a new Release list should be created for the next release
Meetings & Regular Communication:
In general I'd like as few meetings as possible. I'd also love as much asynchronous communication as possible (email, irc, etc.)
Monday Summary Mail
What was completed last week with avatars/names or who completed it, etc.
Tech Call (30 - 60 mins)
This is an as needed call when face to face agreement or discussion is needed. Probably won’t have it or won’t have it often.
Inbox Review Meeting (30 mins)
Mandatory Attendees: Rob, John
Optional Attendees: anyone who wants to attend or present an idea from the Inbox
If you submitted a card to Inbox board, in either the Inbox or Module column, you are expected to attend this meeting and introduce the story behind the card. The goal is to help the rest of the team understand the associated use cases and pain points.
The key to keeping this meeting focused: solutions are not discussed, only problems.
Product Planning Meeting (1 hr)
Attendees: Rob, John, Vivek, Sanchit, Bruce, Jakob
The goal of this meeting is to review all cards from the Planning and Engineering boards ready to move to the “Next Up” column on the Current Development board. For each card we move we’ll make sure there are no outstanding questions or concerns and we may discuss what the next step is (ex: do we need to build a prototype first?). Once all the “ready” cards are moved to Next Up we’ll re-sort the entire Next Up queue according to priority (yes, even cards that were at the top of the list last week may now be moved to the bottom).
We’ll also assign a level of effort estimate to each card. We measure the effort in terms of easy (1 star), medium (2 stars), hard (3 stars). This estimate is based on previous experience (as a company, not individuals): have we done anything similar before, how familiar are we with this domain, do we have any in-house experts, etc. We’ll use the cards to give engineers a sense of how much work is behind this card and also we use it as a signal to the rest of the team how big of a deal a card is (during the product meeting) and to celebrate progress.
Finally we’ll review all the bug cards. If a card doesn’t have enough info or if it’s going to take significant development time (more than a few hours) we won’t move it to “Next Up”. All cards we do move to “Next Up” go to the top of the queue before everything else. Above all else we want to make sure we’re always fixing what’s broken first.
Standup (10 mins)
Teams are free to host their own stand ups, but no MOTECH wide standup will be held. Teams should get in the habit of sharing any interesting information, blocking issues or questions that come up on the mailing list.
Bruce MacLeod
May 2, 2012, 4:42:19 PM5/2/12
to motech-ar...@googlegroups.com
Hello Rob,
Thank you for sending this on. It made for some interesting reading. I did like the grouping that is represented by the different boards. A few comments right off :
1) In our Tuesday architecture discussions, we agreed that groups would take on larger blocks of functionality (OSGi) or a module. Are we still planning to do this ? If so, how do we mix the small tasks that lie outside of any of the current big tasks ? Idea : every group has a mix of major and minor tasks ?
2) Inbox Board :
In the original article, inbox had inputs from customers. Should we develop a mechanism for allowing input from implementation teams ? In a sense, they are our customers. If so, how do we manage this information (we do not have a help desk).
We might also get some ideas from reviewing existing implementations and seeing where the platform fell short.
Bruce
Thank you for sending this on. It made for some interesting reading. I did like the grouping that is represented by the different boards. A few comments right off :
1) In our Tuesday architecture discussions, we agreed that groups would take on larger blocks of functionality (OSGi) or a module. Are we still planning to do this ? If so, how do we mix the small tasks that lie outside of any of the current big tasks ? Idea : every group has a mix of major and minor tasks ?
2) Inbox Board :
In the original article, inbox had inputs from customers. Should we develop a mechanism for allowing input from implementation teams ? In a sense, they are our customers. If so, how do we manage this information (we do not have a help desk).
We might also get some ideas from reviewing existing implementations and seeing where the platform fell short.
Bruce
Rob LaRubbio
May 3, 2012, 12:50:23 PM5/3/12
to motech-ar...@googlegroups.com
Comments inline
On 5/2/12 1:42 PM, Bruce MacLeod wrote:
Hello Rob,
Thank you for sending this on. It made for some interesting reading. I did like the grouping that is represented by the different boards. A few comments right off :
1) In our Tuesday architecture discussions, we agreed that groups would take on larger blocks of functionality (OSGi) or a module. Are we still planning to do this ? If so, how do we mix the small tasks that lie outside of any of the current big tasks ? Idea : every group has a mix of major and minor tasks ?
Yes. I expect most of the tasks that flow through this system will
be of the larger variety and groups will grab those. There also
will be smaller tasks mixed in that an individual dev can grab and
work. We might decide labels would be useful for distinguishing
them. I expect the process to change as we find out what works best
for us.
2) Inbox Board :
In the original article, inbox had inputs from customers. Should we develop a mechanism for allowing input from implementation teams ? In a sense, they are our customers. If so, how do we manage this information (we do not have a help desk).
Input from customers/implementers should have a way of making it
onto the board. The inbox board is public but I'm not yet sure if
that lets people post new ideas, or just see them. That's the main
reason why I wanted to keep the google issues system up. External
users can post bugs/feature requests there. We could then review
and move the accepted ones into our process. I'm still open to
other thoughts and ideas.
We might also get some ideas from reviewing existing implementations and seeing where the platform fell short.
Would we do this review on our own, or would we sit down with the
implementation team to gather feedback?
-Rob
-Rob
Reply all
Reply to author
Forward
0 new messages