In our Product Visioning series, we have come to an important stage where we have to guess a tentative timeline for the prioritized feature list.
Ideally, for agile teams, it would be great if they could start working without a need to guess the release timelines. And the team could use the average of first 3 or 4 sprint velocities to extrapolate the future. This would be more realistic and could improve predictability.
But, in reality, there may be situations where the team had to guess release timelines and make some soft (or hard at times!) commitments around it. In such situations, how do we do it? I’ll share one of the techniques I’ve used to reasonable levels of success.
The Iron triangle:
In the mid-1980s, Dr. Martin Barnes created the Triangle of objectives. The triangle demonstrates that scope, cost and time are interrelated. We may not be able to adjust one without influencing the other two.
Levers:
The team has to arrive at a timeline for the high-level scope given. Unfortunately, in the industry, it has been a practice to keep all the parameters of the iron triangle as constant. Often times, this leads to challenging situations for the teams. All of us would have faced such a situation in our career.
Having said that, in my experience I’d noticed that, all three levers need not be constant always. If we have an open conversation with the stakeholders, (assuming we work collaboratively and with mutual trust), we may be able to arrive at opportunities that could help team come up with a realistic plan.
Say, there might be a time pressure for the business/stakeholder/client to release the product on or before a particular date to meet the compliance constraints. In that case, the scope could be a manageable variable.
When Scope is a ‘Must Have’ constant due to a business reason (say competitor parity or business edge) time could be a variable.
Understanding the constraints and opportunities and collaboratively arrive at rational levers for the project, with stakeholders, is extremely important for the success of the project.
Let us look at some preparatory steps.
Definition of Done (DoD):
The Team has to arrive at what is “Definition of Done” for them, that is when will the team say a story is complete. Usually, this may include Development, Testing, Deployment to staging and/or production, Performance profiling, etc.
Availability:
Another useful information to have is the list of available people with their skill set. It would be better if the team could know the availability of people with some necessary and special skills for the project like UX, Architect, DevOps, specific tech stack, etc. Some times they might be shared across multiple projects due to scarcity or other reasons. Hence availability plays a very important role in planning.
RAID (Risks, Assumptions, Issues, Dependencies):
We all know the importance of RAID. I’m not going to elaborate these in this blog as this calls for a series on its own. Even if the team doesn’t know all the details of RAID, at the minimum, it is very important to capture business and technical risks and assumptions at a high level.
NFR:
One of the very important considerations is NFR – Non Functional Requirements.
This includes performance numbers like:
- Number of concurrent users to be supported
- Data load to be handled
- Scalability
- Response times expected
- Compliance related constraints
- Availability requirements
- Accessibility constraints
- Safety
- Interoperability
- Maintainability
- Disaster recovery
- and so on…
Since there are more areas to touch upon, I’m planning to do this in 2 parts.
<end of part – 1>
In Part – 2, let us explore:
Definition of Readiness:
Raw velocity exercise:
Initial Guess:
Adaptive planning:
Making commitments with caveats:
Points to note:
- At release planning level, it is preferable to be conservative on the estimates and assumptions. While we move closer to development, say during Sprint Planning meeting, we could be aggressive in our estimates.
- From experience, we have noticed that the scope could increase by 20+% when we try to elaborate stories further.
Previous Articles in Product Visioning series:
Product Visioning: https://pm-powerconsulting.com/blog/product-visioning-5-steps-scoping-software-projects/
Product Visioning: 1. Elevator Pitch: https://pm-powerconsulting.com/blog/product-visioning-elevator-pitch/
Product Visioning: 2.1 User Persona: https://pm-powerconsulting.com/blog/product-visioning-2-1-user-persona/
Product Visioning: 2.2 User Goals, Pains and Gains: https://pm-powerconsulting.com/blog/product-visioning-identifying-right-target-persona/
Product Visioning: 2.3 Building Hypotheses using Persona and their Goals, Pains and Gains: https://pm-powerconsulting.com/blog/product-visioning-2-3-building-hypotheses/
Product Visioning: 3.1 User Journey Map: https://pm-powerconsulting.com/blog/product-visioning-user-journey-map/
Product Visioning: 3.2 Features-Advantages-Benefits: https://pm-powerconsulting.com/blog/product-visioning-fab-feature-advantage-benefit/
Product Visioning: 3.3 Prioritization of backlog: https://pm-powerconsulting.com/blog/product-visioning-3-3-prioritization-backlog/
Product Visioning: 4. Sizing: https://pm-powerconsulting.com/blog/sizing/
