In August 2019, we presented a co-hosted webinar with AIPMM – Predictable Delivery: The Power of Estimating and Forecasting. We received so many great questions on the topic and have included answers to each down below. Thank you all for engaging in our webinar!
Q&A
Would you estimate bugs? Are production bugs part of emergent buffer?
Bugs are traditionally not estimated because most of the time in fixing a bug is the root cause analysis. A common pattern with teams is to select a fixed number of bugs to address each sprint. Bug fixing and production issues just show up in the team’s velocity, which is lower than it would be without bugs and production issues. Bugs and production issues are therefore not part of the emergent buffer but are part of the overall equation. I recommend tracking capacity that is allocated to bugs and production issues because this data informs decision to address tech debt, upgrade infrastructure, and expand headcount.
General Use of Agile – My perception is that Agile is being used typically for software. How extensively is Agile being used for non-software products?
Funny you should ask. Agile, which is really empirical process control, has been embraced well beyond the software world. “Campbell Soup recently used agile strategies to launch a new Epic Crunch Goldfish cracker in nine months, much more quickly than usual.” You can read about it here: Are You Agile Enough for Agile Management?
Shouldn’t QA estimates be taken into account when predicting the delivery timeline, and to figure out how much a project costs?
Yes, if you have a dedicated QA period or regression sprint that happens before a release than it does need to be included in your plan.
Curious if, in your experience, any differences (subtle or significant) exist when applying this approach/mindset between version 1.0 products and say, the 37th release of a product?
Absolutely. Assuming the 37th release of a product is an incremental improvement in a mature market (i.e., this is NOT the release where you move the product into the cloud or add a new technology, like an augmented reality module) then traditional market research techniques work well to gather requirements, there is an existing user interface that users understand and to which new features will conform, and the level of uncertainty or emergence is low. Agile techniques can still reduce risk in these situations but I would first apply them to the higher risk product initiatives at the company, where they will yield more significant benefits earlier.
I always receive this question ‘what’s your go-to-market strategy’? Is there a method or tool or even a resource that I can have more information on this go-to-market strategy topic?
Great Question! We have a comprehensive article on Go-to-Market Strategy that explains how to develop this strategy and what questions to consider. It also includes a link to our templates that you can order online to provide you with the framework you need to develop an effective Go-to-Market Strategy. If you just need a single template to organize your thinking, the Product Management Lifecycle Toolkit should suit your needs. If you’re new to working on marketing strategy, then I’d recommend you use the more comprehensive Product Management Office Professional template set which provides additional tools to help you develop each piece of your marketing strategy.
Stakeholders make decisions based on what has been communicated for timelines but often schedules slip. What is a good way to encourage accountability on what has been committed?
This gets to the point of the webinar – being able to hit deadlines is important. Agile requires discipline and in return the organization gets visibility and product managers can better manage stakeholder expectations. Nevertheless, it is human nature that under stress, process and discipline crumble. Here are two tips that should help counter these problems:
- Teams need adequate coaching to understand how to run a disciplined process and use the data they are collecting to better set and meet expectations with stakeholders.
- Enable the team’s success with real ownership. Accountability goes up when the team feels real ownership over the plan and the schedule. Give a team a deadline that was forced down their throat and they won’t perform nearly as well as to hit a deadline that was built on the team’s own estimates of effort. It becomes a matter of personal and team pride to achieve the goal that the team committed to.
I am new to product management and would like to know how much value Product Managers can add to the Story pointing session and how? The product managers do not design, develop or test in the sprint.
You’re right that the Product Manager is not going to add value in trying to estimate story points for a user story during the Sprint Planning session. What I’ve seen work very well in the past is to split the Sprint Planning session into two parts:
- In the first meeting, the PM explains the problems that need to be solved, either with a problem scenario/market needs description, or in an Epic or Feature that he or she has written. The rest of the team asks questions and there’s a constructive dialog to increase understanding of each need.
- The scrum team then has a second meeting without the PM present to huddle and work on story point estimates. After that meeting, they share these estimates with the PM, and then agree together, based on product priorities, which user stories should be included in that sprint.
How do you estimate the duration of a story point?
Story points are an estimate of the relative measure of effort. Estimates are just that. We want the team to get close but it’s not a guarantee, and we don’t want to imply that story points provide greater precision than they actually do. Velocity, which measures how many points the team achieves in a Sprint, in essence is estimating the duration of a story point. But remember it is an estimate.
Where can I learn or read more about Product Backlog Grooming?
We hosted a guest blog on this very topic earlier this year. Take a look at this blog post, Product Backlog Management – 10 Tips for Product Managers, which should help you with some great tips.
What about tech debt?
The more tech debt you have, the less you can accomplish in a sprint, and the greater chance that bugs will emerge in areas of the code that you did not anticipate. Developers should be encouraged to refactor code as they come across it to reduce tech debt. This is the XP principle of continuous refactoring.
Is your definition of a story point roughly four hrs?
Part of the reason to use story points is to not equate it so directly to a time estimate. But many teams do. I’ve seen story points be about a half day of effort but what I see most common is teams start with equating a story point to an ideal developer day. Of course, how a team wants to think about it is up to them. You should avoid the temptation to avoid converting story points into hours though. Using real data to calculate velocity allows you to understand how much effort can be delivered in a single sprint, so that should become the unit of time you use to build schedules and roadmaps.
What does “done” mean when you are releasing weekly and adjusting the roadmap monthly as in some startups?
Each team decides its own definition of done for a user story. Generally, it means all acceptance criteria are met, code is checked in, unit tests are created, and any other standard to which the team wants to adhere.
If as a new Product Manager, your task is to oversee the redesign and redevelopment of an existing complex web application, what would be your very first steps in outlining the process for this redesign?
I’d start with a story map to understand the personas, their goals, and the functionality of the application. I would use the story map to structure discussions about what needs to be retained, what can be improved, and what can be retired so that user value is delivered with the first release. You can read more about story mapping, in the larger context of how to understand your customer’s journey, with this helpful blog post on customer journey mapping tools, written earlier this year by Pamela Schure.
How do you plan for support work, which comes in (non emergent)?
For non-emergent support work, you prioritize it against other goals for the product, such as roadmap work. Usually this comes down to deciding what percent of the team’s capacity should go towards the existing business and retention versus new customer and growth.
How do you get executive management to better understand changes in business priority that affects estimating/grooming/predicting?
Reading between the lines of this question, lets take an example where product management runs quarterly planning meetings to set priorities with the executive team and where the product team is about to embark on a major capability that will take most of the upcoming quarter to complete.
The product manager needs to make it clear to the executives that if priorities are changed, because the current capability cannot be released incrementally, any work up to that point would be put in the icebox. The work becomes inventory and any commitments tied to that capability would not be met. Therefore, although the executives always retain the right to change priorities, for this quarter, the team is asking that the executives hold the ship steady for 90 days.
Great presentation about developer velocity prediction. Love to hear more thoughts on definition planning, especially considering design is so subjective.
While design work, the output of a good user experience (UX) team, can itself be very subjective, the user research used to develop designs can be predictable and time-bound. When I worked with a great UX team that supported an Agile development team, they had a very repeatable, predictable process they would use to conduct user research, and have the results ready in time for sprint zero. The key was for the sprint team to be able to forecast what parts of a user experience they would need input on by which sprint, so that the UX team could then plan its research efforts accordingly.
Where does the truth live? Where does a complete description of the system live? In code? Tests? Specs?
This varies by team. Assuming I am working on a product that does not require traceability of requirements, I personally like to maintain basic documentation of the capabilities and decisions in a wiki and a story map. Once the requirement is turned into a ticket (for example a Jira ticket) and put in a sprint, the ticket becomes the source of truth. Once it is developed, the code and unit tests are the true system of record. I’d like to tell you that the wiki, the dev ticket, and the actual implementation stay perfectly in sync. But in my experience, they don’t. It is a lot of effort to make that happen and for many contexts, keeping all the documentation in sync is not the highest value activity for the product team.
These questions were answered by Greg Cohen and Roger Snyder.
Your Questions Answered By:
Greg Cohen
Senior Principal Consultant
Greg Cohen is a Senior Principal Consultant with 280 Group and a 20-year Product Management veteran with extensive experience and knowledge of Agile development, a Certified Scrum Master, and former President of the Silicon Valley Product Management Association. He has worked and consulted with venture startups and large companies alike, and has trained product managers and product owners throughout the world on Agile development, road mapping, feature prioritization, product innovation, product life cycle process and product management assessment. Greg is the author of the books Agile Excellence for Product Managers, Strategy Excellence for Product Managers, and 42 Rules of Product Management, as well as a speaker and frequent commentator on product management issues.
280 Group is the world’s leading Product Management training and consulting firm. We help companies and individuals do GREAT Product Management and Product Marketing using our Optimal Product Process™.
