One of the toughest subjects for every software project is when it’s going to be finished. With traditional waterfall approach plenty of time is spent on analysis and estimation, and still, most of the projects are not completed by the deadline. Estimations that were too off contribute to this a lot, as well as the enormous level of uncertainty that software development has — after all, if something has been done before then there’s a library or a service that can be used. Otherwise, it’s entirely new territory for the development team.
Estimations are misunderstood
The truth is that software engineers are terrible at estimating their work. One of the most used techniques is "just double it” approach which is still off by order of magnitude. I know a project estimated to take a month that wasn’t finished in a year and the other one that took about six months instead of a week. Sometimes implementation takes less time than expected but it’s so rare that it can be considered as a statistical error. It's a big problem as incorrect estimations can have severe implications for the business.
A misunderstanding between managers and developers makes a huge contribution to this problem. When a developer is making an estimate, he thinks of the minimum time a task at hand is going to take if nothing unexpected happens. I guess you can already see the problem — something unexpected happens all the time and thus the estimation is off. On the contrary, managers, marketing department and everybody else is expecting the work to be done and ready for launch on the estimated date, treating it as the maximum time the task would take.
Cone of uncertainty
Cone of uncertainty is the basic concept of project management that describes the evolution of the level of the uncertainty during the software project. At the beginning of the project, no matter if it’s waterfall or agile, very little is known about its outcome and underlying issues and impediments. The team learns about the project as more work is being done, thus reducing the level of uncertainty. The more refined is the definition of the final product, the more accurate estimations are.
The more variability there is in the project, the more variability you should expect in estimations. The only way to make estimations less variable is to make the project itself less variable. The cone of uncertainty is narrowed down by research and by decisions made during the project that remove that variability. These decisions are mostly about scope, defining what included in the project and who it should be implemented If these decisions are changed later the cone will wider again.
Iron triangle — Time, Cost and Scope
There’s another concept in project management called “The Iron Triangle”. It states that there are three variables in every project — time, cost and scope, that affect the quality. The project manager can adjust these variables, but a change in one of them requires an adjustment in others or quality will suffer. A project can be completed faster by cutting the scope or increasing the budget. Same way, adding to scope will require an increase in time and budget.
There are many interesting things about this concept, but in the context of this post I wanted to point out that in typical agile project time and cost are fixed, so the only thing that can be adjusted is the scope. Usually, we have a deadline that is already defined, and our cost is something we already know — it’s the salary we have to pay our team plus the cost of third-party services we are using. The only variable is we can change is what can be delivered on a given date.
Scope management
Scope management in agile projects is different from traditional waterfall projects. Project scope is all features and requirements final product has, all the work required to create a product. While for waterfall projects scope change is a sign of failure, agile projects treat scope change as something natural as it’s a result of learning about the project and constant improvement. New product requirements can be identified at any time in the agile project. The product manager then prioritizes changes and placed on the roadmap.
In an ideal world, everything that has been planned should be implemented by release date. With a flexible scope, this is nearly impossible to achieve because of new high priority features are identified or various issues and impediments uncovered during implementation. That all affects the final set of features to be delivered. Only a portion of the defined scope can be delivered, so it’s essential to continually revisit the backlog and make sure that the highest valued items are prioritized and implemented before the deadline.
Scope creep is not bad
We’ve been trained that scope creep is something terrible, that change should be minimized and avoided. I think it comes from the world of fixed-price contracts where an ever-changing scope is a risk of losing profit for the company implementing the solution. Typically this happens because the scope is only growing and there’s no way to scale budget and time accordingly. Agile approach can’t fix this unfortunately as it’s not applicable to every project. If there’s no way to manage scope and negotiate the trade-offs of scope change of other project constraints (time/budget/risk/other features), then it’s better to stick to traditional methods.
The reality is that business requirements change all the time and thus scope is changing too. If the requirements are important and urgent enough there’s nothing project manager of the development team can do to stop the scope change. It will either affect the current project or a follow-up project will be scheduled to reflect the change. If the scope is going to change anyway, then the question is only how do we react to the change. In traditional projects, the whole project is slowed down to assess the change and estimate the impact. In an agile project, changes are evaluated throughout the project, and the updated scope is applied at the beginning of each iteration. It’s a much more efficient use of team resources as changes are easily incorporated into the process.
