In software engineering, the magic triangle is a well-known concept to illustrate the relationship between scope, time, and cost of a software development project. Of the three (scope, time, cost), pick two, and the third will magically follow. (It is determined by the other two.) Scope means features (or delivered functionality), time means duration or deadline, and cost typically means number of developers or, more abstractly, available labor.
When I looked up the definition of the magic triangle for my agile methods class, I had to realize that different authors define the magic triangle in a different way, adding a fourth factor, quality, to the mix. Rather than make the triangle a square, the third factor is considered fixed and put into the middle of the triangle (as the referenced Wikipedia article shows). This classic form of the magic triangle makes the most sense to me, as quality is often set a-priori, leaving a project manager to fiddle with any two of the original factors to determine the third. Typically, cost is fixed next so that what’s left for the manager is to trade-off scope vs. time.
Under the (rather theoretical) assumption of a steady state (an established well-working team and a codebase that is already on the right level of quality), the magic triangle also makes sense for agile methods and Scrum in particular. At least it can explain to students some of the dynamics of software development.
In agile methods, one of your goals is to reach and maintain a steady (as high as possible, but not higher to the detriment of evolvability) development speed (called velocity for reasons unknown to me). Speed is measured in features churned out per time period (or story points per sprint in some variations of Scrum). You can only ever reach a constant speed if your codebase supports it, which is to say you have a percentage-wise constant level of technical debt. Thus, with a steady maintained pace, in a given iteration, you will always add the same amount of features and create and fix the same amount of bugs (percentage-wise, again, and on average).
This only ever possibly works if there are no changes to the team, so cost is also fixed. Then, in agile methods, the team can only trade-off scope vs. time, according to the magic triangle. As soon as you have changes to the team, its efficiency will drop, and in order to keep quality up, the trade-off between scope and time will suffer. In other words, to maintain quality, development speed will also drop.
The reality of software development projects, agile or not, is of course regular changes to the people involved. In reality then, the magic triangle can only serve to explain relationships and correlations, but cannot seriously be used to quantify these factors and plan with them. Still, as a teaching device I have found it helpful, and keep using it.
Leave a Reply