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/
4 Responses
Hi Shiv, I can relate to this, it is a real different world.
I was invited a few times to address students appearing for CET exams as an industry person and found it challenging to connect with them. I was able to connect somewhat as one of their concern was what if they do not get into a good college, which I was able to address by sharing real life examples.
Thanks Vasu. College “brand” no doubt helps early on in work life – corporate doors open more easily. But down the line, it is people’s motivation and track record that helps build careers. I am sure we have all seen examples affirming this. I have stressed with the mentees that I work with. An aside, the mentorship program I am involved in spans 4-5 months and so, I have had time to work on the “connect”! Yes – takes time and effort.
Hi Shiv – very well written – thanks for the write-up.
Many years ago I was a volunteer mentor for a couple of youth as part of Dream A Dream’s life skills mentoring program. This was in person mentoring where the mentee and I would meet periodically (usually on a weekend) and discuss general topics. There was no prescribed structure though all mentors did go thru a few hours of in person training. Based on that experience I can corroborate that it takes time for the mentee to open up, especially in that case given their lack of confidence in expressing in English which was the recommended language for communication. Switching to Tamil (in one case where the mentee was from Tamil Nadu) helped.
Can also relate well to your point on swings in mood and engagement level of the mentee and the need for mentor to shift gears accordingly.
I am sure the mentees are benefiting a lot from your vast and varied experience – hope you will come back to mentor more such students after you complete the current mentorships and possibly take a break!
Thank you, Bhasker!