Scope

Development Options

Fixed Time ver­sus Fixed Scope

There are two fea­si­ble de­vel­op­ment meth­ods. While it’s nat­ural to want every­thing done in a fixed amount of time, that does­n’t con­sider the re­al­i­ties of soft­ware de­vel­op­ment. Using a trade-off slider is a great method to com­mu­ni­cate that it is pos­si­ble to fix the time, but as a re­sult the scope must re­main flex­i­ble. This can help in­form the de­ci­sion around what de­vel­op­ment ap­proach will be re­quired for any given pro­ject. By se­lect­ing ei­ther fixed time or fixed scope, it al­lows a cus­tomer to ei­ther pri­ori­tise their scoped fea­tures or the bud­get they have al­lo­cated to the pro­ject. It is para­mount to un­der­stand though - you can’t have both.

Fixed Scope & Variable Time

• Scoping length is longer, typ­i­cally re­quires a lot of de­tail.
• The scope may be­come ob­so­lete by the end of the pro­ject de­pend­ing on busi­ness goals and length of de­vel­op­ment.
• Virtually im­pos­si­ble to guar­an­tee that a scope will not change.

Fixed Time & Variable Scope

• Scoping time­frames will be shorter.
• Faster re­turn on in­vest­ment as de­vel­op­ment can be­gin sooner.
• Certainty in bud­get and spend.
• Scope is fi­nalised dur­ing de­vel­op­ment and can re­spond to chang­ing busi­ness needs.

Fixed Time and Fixed Scope

Gone are the days of the wa­ter­fall method­ol­ogy. Developers were handed spec­i­fi­ca­tion doc­u­ments that were hun­dreds of pages long, writ­ten by busi­ness an­a­lysts that spent months, maybe years, study­ing the needs of an ap­pli­ca­tion. Often, it took less than a week into de­vel­op­ment be­fore that doc­u­ment was al­ready amended be­cause it was out­dated. The first beta re­lease of a prod­uct would be met with an­other cas­cade of changes, and the pro­ject dead­line would slip fur­ther and fur­ther be­hind. This method pro­vided noth­ing but frus­tra­tion for cus­tomers and de­vel­op­ers alike.

For this rea­son, it’s rec­om­mended that the team fo­cuses on smaller it­er­a­tive scopes of work and de­cide on a trade-off be­tween time and scope. This gives the team a chance to pro­vide es­ti­ma­tions with more cer­tainty in the short-term, while be­gin­ning to be­come more fa­mil­iar with the prod­ucts con­text and its re­quire­ments.

Increased Velocity

There is one other fac­tor that can af­fect the time it takes to de­liver a pro­ject, and that is team size. Increasing the size of the de­liv­ery team can po­ten­tially mean fin­ish­ing the pro­ject in a shorter amount of time. However, there are two rea­sons why it is not a vi­able op­tion for all pro­jects:

1. The first rea­son is that of bud­get. Generally, if a cus­tomer opts to fix the time, it is be­cause they have a bud­get in mind for their pro­ject. Increasing the team size will not as­sist in bud­get­ing, but in­stead help to shift the de­liv­ery date for­ward. The ad­verse ef­fect of shift­ing the de­liv­ery date for­ward means that de­ci­sions need to be made faster, which can be dif­fi­cult early in a pro­ject.

2. The sec­ond rea­son is a loss of ve­loc­ity per de­vel­oper. Does the phrase “too many cooks in the kitchen” ring a bell? Adding more de­vel­op­ers does not mean dou­ble out­put, or nec­es­sar­ily even an im­me­di­ate in­crease in ve­loc­ity. A pro­ject needs to be able to be bro­ken into log­i­cal sec­tions to al­low a col­lab­o­ra­tive de­vel­op­ment ef­fort to oc­cur, which is pos­si­ble for some soft­ware pro­jects but may not be for oth­ers.