In many cases we are asked to give a WAG for a project very early in the process. This typically includes the assumptions we made, and any known risks.
As the project progresses it is usually necessary to spend some more time investigating specifics and determine a SWAG (slightly more scientific WAG).
If the project is approved for work further conversations need to occur since people typically have many different assumptions as to what is actually going to be delivered, and when, based on their personal frame of reference.
In the past we typically jump right in to the project development kick-off and in many cases this leads to differing levels of floundering since there is not a well-planned roadmap, and in many cases unanswerable story questions as the product owner has to continually re-engage with the customers for further clarification.
What we propose doing going forward is to have a scoping / road-mapping session (planning) prior to the kick-off process. During this time what we would like to see happen is the follows.
This could be a multiple day process and ideally the entire project team is co-located and available to participate.
Goals
- Have the entire project team on the same page as to what is possible to deliver and when I can be delivered
- The appropriate expectations are set for the different team roles
- Where are specific knowledge gaps required to fulfill requested stories (risk assessment)
- Have an initial prioritized backlog of semi well-defined stories (they do not have to be perfect and we know priorities may change)
- Have shared understanding of what success looks like
- Ability to have development hit the ground running without major roadblocks
How to start
Project Goals
Understand the overall project goals to use as a guidepost during discussions.
Deadlines
Understand the preliminary product delivery dates.
Product Owner
While the product owner is the voice of the customer they should understand the long term vision of the product so they can decide if the customer request makes sense for the product or is something else entirely. They must be able to prioritize and make decisions quickly with the understanding things can be changed later as new stories.
Determine who the developer / product owner liaison is (if necessary). Ideally this person is onsite with the development team regularly, can make decisions in the absence of the product owner, and bridge any conversation gaps between the product owner and development team.
Story Mapping
Ideally the product owner has created a product roadmap and already broken the main stories down into puzzle pieces that will ultimately be assembled into what the end user needs. However, this is never a perfect process and the entire team will most likely need to be involved.
Create a high level stories that need to be accomplished.
Decompose those stories down into smaller stories, until they fulfill the INVEST criteria:
| I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another user story. |
| N | Negotiable | User stories, up until they are part of an iteration, can always be changed and rewritten. |
| V | Valuable | A user story must deliver value to the end user. |
| E | Estimable | You must always be able to estimate the size of a user story. |
| S | Small | User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible |
Initial Development Backlog
Once there is a good story breakdown the items can be broken down into some flavor of priority buckets, such as:
- Must Haves
- Great To haves
- Backlog
Preliminary estimates (guesses) are determined for the highest priority items (Must Haves).
The product architecture should be determined during this process, and the appropriate foundation stories can be created and estimated. Some of which may be completed prior to the development kickoff.
At this point all parties involved should have a good understanding of any remaining known risks and they should be assigned out for a resolution prior to that story being tackled by the development team.
This could include things such as an architecture or technology decision to be determined by the development team, or business rules that the product owner needs to clarify with the customer.
Planning For Success
Understanding the estimates for a preliminary scope is imperative so that the project team can understand the likelihood for success. The information acts as a reference point for any conversations about what scope can be accomplished within the specified deadlines or the product owner’s proposed delivery roadmaps.
Everyone should be aware that things can change. We expect it and embrace it. However, those changes may or may not impact scope or timelines.
We are continuously trying to improve how we kick off a project and expect the above to change over time as we evaluate how well it works and what could still be done better.
I welcome discussion below as we work through what works best for us. If you find certain things work well, or not so well, leave a comment.
