As a product manager, there are several procedures I follow when estimating story points with my teams. Firstly, I ensure that we have a clear understanding of the user story and its requirements. This involves collaborating with the development team and stakeholders to gather all necessary information.
Next, we break down the user story into smaller tasks, or sub-stories, to get a better grasp of its complexity. This helps us identify any potential challenges or dependencies that may affect the estimation process.
Additionally, I encourage open discussions and involve all team members in the estimation process to ensure a more accurate and collaborative effort. This approach fosters better understanding and alignment among the team, ultimately leading to more reliable estimates.
As a product manager, what procedures do you follow when estimating story points with your teams?
It’s ironic that this is an important project management skill. I mistakenly believed that product management didn’t conduct project management, but it does by being able to accurately estimate the work for a project or product roadmap and report it back to management for how long things might take.
Scale the difficulty up using the Fibonacci sequence, and then use sprint planning to get your engineers to come up with a number. Divide your stories into manageable chunks.
The issue arises when one development team is working on several products and engineers are divided among them. This situation is made worse in large company settings when one team depends on the output of another. Then you plunge into the demonic enterprise-scale agile framework, or more accurately, waterfall with agile lipstick.
You can go back to hour estimation and then have the developers clock time against each task if you have a strong engineering manager who is realistic about how long excellent developers should actually take. This is challenging because competent engineering managers who understand this are hard to find.
This is our challenge now. Flat organization with teams working across multiple domains and products. Also, we currently don’t have an EM, scrum master, or project manager. A lot has to rely on the senior developers to help refine and keep to some sort of time line, which can be challenging without dedicated management roles. Without dedicated management roles, the team may struggle to effectively coordinate and prioritize tasks. This can result in missed deadlines and a lack of overall progress.
I’ve had the bad experience of leading a team similar to this.
The issue is that since the time spent by your developers is so valuable, spending time on sprint preparation would significantly reduce their productivity.
Instead, you can create a 2-week sprint and then transfer the things that need to be completed into it.
Ask your engineers to use a time tracker to record their efforts as they work on them. Jira’s work is enough.
As tasks need to be completed, add them to that sprint.
Finish the sprint, then evaluate the effort put in by each task. The effort put forth can then be used to evaluate efforts on particular areas. In a sense, you are “working backwards”.
You can then plot effort and a rough roadmap, provided that you are writing distinct user stories that are easy to understand.
However, I made it plain to your management what was actually going on and that if they wanted more visibility, you would need to involve the developers in more planning in order to estimate effort across projects, which may not be what they really want.
Just now, I brought up the subject with my lead. It will never be entirely correct. When you look at it from a high level, it’s really just a mechanism for us to make an estimation of how much can fit into a sprint, but it’s not a precise representation of how much work a developer must actually complete. Generally speaking, it’s relative but not quite accurate.
Gaining a general understanding of effort is, in my opinion, somewhat beneficial, but it can’t be taken as gospel. As the number increases, the accuracy of the Fibonacci sequence decreases due to divergence.
Use it as a tool, but don’t take two 3-point stories as being absolutely equivalent in their efforts.
Estimating story points is a crucial aspect of Agile project management, as it helps teams plan and prioritize their work effectively. Here’s a general procedure that product managers can follow when estimating story points with their teams:
Gather the Team: Bring together the cross-functional team that will be working on the user story. This typically includes developers, testers, designers, and any other relevant roles. Having a diverse perspective is essential for accurate estimations.
Understand the User Story: Ensure that everyone on the team has a clear understanding of the user story or the feature being estimated. Discuss the requirements, acceptance criteria, and any related documentation. If there are any ambiguities or questions, clarify them before proceeding.
Use a Consistent Estimation Scale: Establish a consistent estimation scale for your team, such as the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.) or a modified version like t-shirt sizes (XS, S, M, L, XL). This scale should reflect the relative complexity of the tasks, not the time it will take to complete them.
Comparative Estimation: Start by comparing the user story to previously completed stories or tasks. Select one or more reference stories that the team is familiar with and has already estimated. Then, discuss how the current user story compares in terms of complexity, effort, and risks.
Discussion and Consensus: Encourage an open discussion among team members. Each team member should share their perspective on the complexity of the user story and the effort required to complete it. It’s essential to allow team members to express their opinions and concerns.
Roundtable Voting: After the discussion, conduct a roundtable voting session. Each team member privately assigns a story point estimate to the user story. The team should aim for consensus, but it’s not always possible to achieve unanimity. A common practice is to use Planning Poker cards or a digital tool for this voting process.
Discuss Outliers: If there are significant discrepancies in the estimates, have a focused discussion on why some team members gave higher or lower estimates. This can lead to a better understanding of the story and may result in adjusting the estimate.
Revote if Necessary: If consensus is not reached or if significant new information comes to light during the discussion, consider revoting until the team converges on an estimate.
Record the Estimate: Once an estimate is agreed upon, record it along with the rationale behind the estimate. This documentation helps with future reference and can aid in tracking the team’s accuracy in estimation over time.
Repeat for All Stories: Continue this process for each user story or task in the backlog that needs estimation.
Monitor and Improve: After implementation, compare the estimated story points to the actual time it took to complete the work. Use this feedback loop to improve estimation accuracy in future iterations.
Remember that story point estimation is not about precision but about relative sizing. It helps the team understand the complexity of work and plan accordingly. Over time, the team will become better at estimating, which is one of the key benefits of Agile methodologies.
Many insightful comments can be found here. When you don’t use any estimates, I was curious how you guys communicate any timetable with the leaders, founders, and managers that you report to.
How can you control expectations regarding the delivery schedule? Particularly when deadlines are used or when product releases are planned.
It is true that the number increasing can also be very erroneous; therefore, I make sure that the tasks are simplified to the bare minimum.
@EvaRichardson, Thanks for the very detailed insight. Was very helpful.
@AmyWalker I track my progress using story points. After a few sprints, you can determine the typical points you can produce for a given sprint, which means that eventually your story points will translate to hours or days.
My main concerns are getting very high-level knowledge of relative size and verifying that the team has a solid comprehension of the story. I don’t really care about the estimation itself. When you attempt to link estimates to time or dates, they will typically end up being inaccurate.
We typically review the story for three to five minutes and “estimate” for one to two minutes. I believe estimation does two things:
Builds shared knowledge and draws attention to team divergences.
Makes the team feel compelled to inquire.
Although my leadership would really like to have more precise estimations, I don’t think they will include that in the engineers’ performance review.
Excellent approach! Estimations are inherently uncertain due to various factors such as unforeseen challenges or changes in requirements. Therefore, it is important to approach estimations as a tool for fostering collaboration and identifying potential roadblocks rather than expecting precise predictions. Additionally, focusing on continuous improvement and learning from estimation discrepancies can lead to more accurate estimates over time.
I agree with this. Everyone will realize that this is a “thumb in the wind” activity and that we are all working together to solve it if we ask about confidence levels.
If someone expresses a lack of confidence, we should offer support or take a discovery surge into account. Clarity improves confidence, just like it does in everything agile.
Same. I will ask for points, but not always; I don’t add them up or anything. The only true question is, “Do we understand this?” as well as, “Are there dragons here?” It’s time to split the task or reduce the scope if someone says it’s an 8, otherwise it won’t get finished.