The Conflict Between Estimates, Deadlines And A Working Product

Lately, I have been struggling with some of the management side of projects. The concepts of estimates, deadlines and work completed do not always align in ways that make people happy. The problems with estimates and deadlines had pushed me closer to agile methods before, but not all projects can be run in the manner you want them run if you are dealing with a client. So, I was having problems reconciling all of this when I saw a post from Matt Block asking Is Working Software Enough? Matt highlights an interesting problem:

The team seemed very concerned about achieving a high velocity. They showed reluctance to slow down and spend more time in “grooming” and planning. Previously, in an effort to optimize velocity and reach “hyper-productivity” the team had capped the amount of time the product owner could use for grooming at 5% of the sprint. However, I was starting to think that really wasn’t enough time. It was forcing a lot of important design decisions off onto myself and the UX designer without getting the opportunity to explore different options and get feedback from the development team. There may be situations where this setup works well, however I have a very smart and talented development team and I felt that spending more time grooming and brainstorming potential solutions to the problems on the backlog with the team prior to designing the solution would, in the end, result in a much better product.

Basically, the development team was so focused on the amount of work to be completed in a specified amount of time that they forgot the goal of producing a better product. This type of stress normally comes from the project manager, they were worried about the calendar. When did developers start worrying about the calendar?

Part of the problem is that developers are required to estimate project tasks. In traditional or waterfall projects, these estimates are given in hours or days. With agile methods, developers are often asked to only provide a relative difficulty of the task. For relative difficulty, I have seen various measures like points (based on the fibonacci sequence), t-shirt sizes (S, M, L, XL), donuts, beans and many others. The problem with relative measures is that they do not relate to the calendar directly. In the end, most clients want to know when a selected feature set will be complete, and sometimes there are other calendar pressures like launching before a conference or staying aligned with some business cycle (like monthly accounting). Why is agile used in these scenarios? Because agile methods are related to getting a working product. You implement a feature during a sprint, instead of various people working on tasks that are not entirely related to each other except due to related due dates.

Another problem with estimates is that they are typically not related to the developer doing the work. One way that this issue has been avoided is to have the developer scheduled to do the work, to estimate the task. However, we all know that schedules and reality do not always see eye to eye, so you may have a developer working on tasks that they did not estimate. Invariably, there are differences in the actual hours needed to complete the task and the original estimate. Some of this is due to the estimate-developer mismatch, but sometimes it is just a matter of expectations. In most projects, developers are allocated as 100% utilization for the project. In reality, this is almost never true. During a week, the developer will at least have project status meetings or scrums. In many agile methods, a daily 15 minute scrum is required, which means that the developer already loses 1.25 hours for the week. If you add in the time to process emails, about 30 minutes per day, you have lost 3.75 hours or almost 10% of your week. This does not include any other types of distractions, and the best you can expect is 90% utilization from the team members.

So, we already have the fact that estimates are likely flawed, the project plan is possibly flawed due to lower than expected utilization, and the potential for a business driven deadline, all pulling for attention when looking at the project schedule. Agile methods have attempted to remove the first two issues, by using relative difficulty as the estimate, but that often gets translated to effort hours in the long term in order to determine an approximate date when the project will be complete. Obviously, we could talk this problem in circles, because without data, there is no proof of what could happen or at least data showing trends of what has happened.

In agile methods, the concept of velocity has tried to make use of the trend of previous sprints’ work completed. However, this trend tends to become a target instead of just a trend based on data. Developers try to increase their velocity, because it makes them feel productive, and management likes to see the velocity remain stable or even increase over the life of a project. This is the problem with data, it makes people feel like they can make decisions about the project, while they are forgetting about the main goal of developing a solid, functional product.

What if the only metric that was measured was total points delivered? Or we measure points delivered as a percentage of the required points for the minimum viable product? This is what we really want to know. Is the product done? If not, how much work needs to be done until the product is minimally ready for launch?

Enhanced by Zemanta

5 thoughts on “The Conflict Between Estimates, Deadlines And A Working Product”

  1. Thanks for the post!

    In my experience, there are important differences between the estimating, management, and design of projects when they are meant for internal business use (that is primarily the type of development I am doing now), especially “one-off” projects. A lot of what I read about the software development process seems more geared toward much bigger and/or commercial projects. I think estimating makes less sense when, to be honest, you could hack out the finished product in a day to make the user happy.

    In particular, one of the challenges of the smaller and sort of ad-hoc projects can be: How do you decide when you are done? I haven’t come up with a great answer, but I think one of the keys for me is to always ensure that I have a user who is “chomping at the bit” for whatever program I am writing. That gives a great motivation to finish and also the chance to get very clear feedback on the results.

    Like

    1. Shannon,

      Most of the methodology doctrine is definitely aimed at public products or large-scale projects. Estimates for one-off, or small one-developer projects are definitely not as useful except for getting an idea of when it would be ready.

      In terms of “when is it done”, for those small projects I would recommend using the idea of a product backlog from Scrum. It could have lower level tasks than a typical product backlog, but for your use it could provide the visual reinforcement that you need. Also, for most projects you are never really done. There is the minimum viable product (which is the original done), and then there are the features that users may have wanted but couldn’t get in time or things they thought of later.

      Like

  2. Basically, the development team was so focused on the amount of work to be completed in a specified amount of time that they forgot the goal of producing a better product.

    The team’s ultimate goal should be to deliver value. That’s not to say that a ‘better product’ is a bad thing, but it should not be the teams first priority.

    Another problem with estimates is that they are typically not related to the developer doing the work.

    On a self-organizing team, cross-functional team members should be working on various tasks during the sprint. An estimate of relative complexity from one member of the team is still valid when another member of the team does the actual work. Differences in estimations will even out in the end.

    In most projects, developers are allocated as 100% utilization for the project. In reality, this is almost never true.

    Using a commitment driven approach, where you determine your available hours before committing to any work, solves this problem.

    Agile methods have attempted to remove the first two issues, by using relative difficulty as the estimate, but that often gets translated to effort hours in the long term in order to determine an approximate date when the project will be complete.

    Conflating relative difficulty and effort hours, outside the context of a velocity, should be viewed as a smell and not accepted as the status quo.

    In agile methods, the concept of velocity has tried to make use of the trend of previous sprints’ work completed. However, this trend tends to become a target instead of just a trend based on data.

    Agile promotes continuous improvement. Scrum specifically promotes a culture of “Inspect and Adapt”. There is nothing wrong with using an established velocity to help predict the future, that’s the point of establishing a velocity and using it for release planning. The team should be inspecting and adapting frequently so that they can improve their velocity/code quality/value/etc.

    This is what we really want to know. Is the product done? If not, how much work needs to be done until the product is minimally ready for launch?

    The goal of Scrum is to have potentially shippable software at the end of each iteration. In other words, your product is never “done”, it just gets more “done” as you iterate and add value. Also, the way you can approximate when a certain set of features will be ready for release (what most people mean by “the product is done”) is by using your velocity and the total number of points remaining. With those two values you can see about when everything will be completed. If that date is too far in the future you can remove scope or find ways to increase the velocity.

    Like

    1. Clayton

      I think in some spots you are taking the wording too literally, but in others I can understand your point. I guess part of the problem is that in my experience, the agile processes that are used are not entirely followed, so some corruption of the process occurs. Thanks for the excellent comment though.

      Like

Comments are closed.