00:00:00
When the manager really wants something done in July, you can feel pressured to produce estimates that align with that timeline.
00:00:04
However, this tendency often exerts downward pressure on your estimates. Just because you declare that something will be done by a certain date, or you produce a document stating it will be completed by July 30th, that doesn't change the underlying complexity of the project. You can present these estimates in various forms, but the reality remains: there is still a range of possible outcomes and numerous factors that can go wrong from the beginning to the end of a project.
00:00:22
So, the question arises: can we manage this process better? I believe we can, or I wouldn't be up here speaking today. The key to producing better and more effective estimates is to focus on the aspects of estimation that people excel at, while avoiding false precision. Just because a calculation yields five decimal places does not mean that each of those details is meaningful.
00:00:43
For example, presenting an estimate as $186,430.75 is likely not valuable. Instead, it may be more productive to communicate that the cost will be between $150,000 and $200,000, provided those numbers are accurate based on your calculations.
00:01:12
When discussing estimation, it's important to consider the factors that determine how long a feature will take to develop. If I say I can finish an admin report by Tuesday, there are key factors that influence the timeline: how complicated the task is, the skill level of the developer assigned to it, and the amount of time they can dedicate to that task, along with the overhead for project management and testing.
00:01:51
As developers, we often struggle with time estimation. We tend to be optimistic about how much time we will spend on actual development versus distractions like checking social media. Furthermore, we may overlook other necessary components of a project like deployment and management. However, time on task tends to remain consistent over time.
00:02:32
For instance, my meeting schedule typically does not change much from week to week, and the time required to test a feature also remains relatively constant. Thus, while predicting specific outcomes may be challenging, we can measure and analyze these factors to get a better understanding.
00:03:01
Regarding the skill of developers, we often struggle to estimate performance in this area too. It's also not helpful to suggest that one developer will be faster than another in front of a client or manager during estimation discussions. Performance evaluations should occur in a constructive manner, but during project estimations is not the right time.
00:03:55
If a team remains consistent, its collective skill will generally stay the same, which gives us a stable metric to work with. Regarding the complexity of tasks, developers tend to excel at estimating the relative complexity of different projects. If I present several user stories from a future project, I can expect broadly agreement on their complexity, even without specific context.
00:04:37
To put it plainly, we can make relative comparisons about complexity effectively. This capability leads us to how we should perform our estimations, focusing on elements we are confident we can assess and allowing the unknowns to guide other aspects.
00:05:40
In Agile projects, we use 'story points' as a measure of complexity. Our estimates are based on the assumption that while individual stories might differ in time required, stories that share the same point value should take a comparable amount of time to complete.
00:06:42
When I claim that our team can handle 15 points of work in the next two weeks, I do so with a reliable level of confidence. This pacing allows us to maintain expectations and provides clarity about project timelines. This method of estimation is akin to calculating the duration of a trip to the airport based on known distances and average speeds.
00:07:14
While this is a practical approach, it does require some assumptions about the consistency of your team's size and working environment. These calculations also necessitate a few iterations to arrive at reliable estimates. If you can effectively break your stories down into uniform sizes, you will find greater success in your estimations.
00:08:01
It is also crucial to establish a reliable process for assigning these point values to user stories. A first step is categorizing stories into one, two, three-point values, or larger if necessary, to maintain clarity in assessing complexity.
00:08:57
In establishing these ranges, it is vital to keep your estimates flexible as certain elements will inevitably shift throughout the project. It can be more effective to communicate a range rather than a fixed value at the project's start.
00:09:36
For instance, you might say that the project's total complexity will range between 120 and 145 points, with an estimate that a single point represents an estimated five to seven hours of work, depending on the tasks at hand. This approach fosters flexibility and ensures you account for various project conditions.
00:10:41
While this method may seem hand-wavey—because it is—it still yields viable estimates far faster. Knowing your low and high hour estimates allows you to arrive at a credible range for total project costs.
00:11:45
Often this range turns into something that the client finds unwieldy, so breaking it down to midpoints can help clarify expectations. What is essential is maintaining a comprehensive understanding of your estimates and presenting them with humility to build trust.
00:12:32
Acknowledge that changes will occur and outline specifically which stories will evolve over time. As you navigate project estimations, you and your stakeholders are essentially working together towards a common goal.
00:13:01
Ultimately, continuous communication and a shared understanding of the process contribute to a smoother project journey.
00:13:33
Thank you for your time.
