Assume the team is composed of:
- There are several stakeholders acting as product manager, making feature requests and requiring a high level view of the project. They are the work creators.
- One project manager coordinating everything. The PM vets, routes, value-adds, chases up, and drives completion of work.
- Handful of technologists and suppliers the project manager is coordinating. They get work done.
There are two main control documents: product backlog, project plan.
Product Backlog
The first is a product backlog, used to capture all the new ideas and feature requests. The backlog should be kept in a wiki, google doc, or similar shared location. For a small team and project the project manager is the chaperone of the backlog, but anyone can put new entries into it.
The backlog is the only way that new feature requests can enter the project.
The backlog is the only way that new feature requests can enter the project.
Backlog entries have these attributes:
- Who requested
- When requested
- Enough detail so everyone roughly knows what is being requested (but no more, not at this point)
As you start adding in backlog requests, put them into a few simple groups:
- Required to "make the sale", acquire investment, unblock the team, or otherwise business critical in nature ("It's game over if we don't do this right now!")
- Required as part of the release currently being worked on ("We can't deliver the new release without this.")
- High want for the next release coming up after the current release ("I really want this in the current release, but I'll settle for the next release coming up." "All our competition has this feature.")
- Futures, nice-to-have, everything else ("Cool idea, but we don't absolutely need it right now")
If people other than the PM add new entries, they should throw them into the bottom of the list but can note where they would like the request. Let the PM move the request into the main backlog as part of their vetting and value add functions.
As backlog items are completed, edit them out of the backlog and into a completed list. Note when they were completed and by whom.
As backlog items are completed, edit them out of the backlog and into a completed list. Note when they were completed and by whom.
Tactical Plan
The tactical plan is a simple document written by the PM for the stakeholders that covers:
The stakeholders use the weekly meeting to make changes to the tactical plan. For efficiency, unless it is an absolute crisis or a critical mistake is being made, the stakeholders agree to not change the tactical plan more frequently than weekly.
The PM and stakeholders also try to avoid creating a long list of partially done tasks, instead allowing tasks to run to completion and not interrupting them with a new task assignment unless the work is really of zero value.
The PM and stakeholders review the recommended promotions from the backlog to the tactical plan and agree on which items to add to the tactical plan in the next 1-2 weeks based on expected free resources. As new backlog items are selected, makes sure expectations are aligned about what it means to be "done" for each item.
The PM and stakeholders review the roadblocks, issues, and risks to problems solve and make changes to the project and team.
Spend requests are reviewed and approved/denied.
The PM revises the tactical plan and backlog after the meeting is complete and circulates it.
Intentional Exclusions
Other items could be put into the project plan such as QA test coverage and bug lists, code stats, and operational concerns. However, with a really small team and unproven product, these may not be of much value yet.
Summary
Keep things as simple and light as possible when managing a small team working on an unproven product.
Use the backlog to give the stakeholders a voice and to not clutter and thrash the tactical project plan.
Use a one week review cycle to balance flexibility with efficiency.
- Two lists of tasks:
- Last week - what got done, who delivered the task, when done
- What tasks are on-going from last week, who is involved with each, a rough estimate to complete each, reasons for date changes (if any)
- List of (anticipated) free resources and when available
- Suggestion of next tasks to put on the tactical plan as taken from the backlog and from other sources
- List of dates and description for delivery aspirations, commitments and estimates. Highlight changes from the last meeting
- List of roadblocks, issues, and risks
- List of budget/spend requests
Weekly Review
About once per week, the project manager updates a tactical plan for review with the stakeholders.
Before the meeting the PM has done their homework, getting fresh information from the rest of the team and suppliers. The PM has taken a quick scan through the backlog, looking for fresh, urgent additions and is prepared to make recommendations of which should become new tasks.
The project manager sends out the updated backlog and tactical plan in advance of the meeting.
The PM and stakeholders also try to avoid creating a long list of partially done tasks, instead allowing tasks to run to completion and not interrupting them with a new task assignment unless the work is really of zero value.
The PM and stakeholders review the recommended promotions from the backlog to the tactical plan and agree on which items to add to the tactical plan in the next 1-2 weeks based on expected free resources. As new backlog items are selected, makes sure expectations are aligned about what it means to be "done" for each item.
The PM and stakeholders review the roadblocks, issues, and risks to problems solve and make changes to the project and team.
Spend requests are reviewed and approved/denied.
The PM revises the tactical plan and backlog after the meeting is complete and circulates it.
Intentional Exclusions
Other items could be put into the project plan such as QA test coverage and bug lists, code stats, and operational concerns. However, with a really small team and unproven product, these may not be of much value yet.
Summary
Keep things as simple and light as possible when managing a small team working on an unproven product.
Use the backlog to give the stakeholders a voice and to not clutter and thrash the tactical project plan.
Use a one week review cycle to balance flexibility with efficiency.