Scope

The Scope Process

The scop­ing process fol­lows a de­sign think­ing ap­proach and is un­der­pinned by the di­ver­gent and con­ver­gent method­ol­ogy. This user-cen­tred ap­proach is pre­sent through­out the fol­low­ing stages of scop­ing:

• Understand: Gain a strong un­der­stand­ing of the cus­tomer and the prob­lem they are try­ing to solve.

• Observe: Perform user test­ing to gather in­sights and val­i­date the prob­lem state­ment.

• Ideate: Get cre­ative and brain­storm dif­fer­ent ideas to solve the prob­lem.

• Prototype: Wireframe and pro­to­type the strongest so­lu­tion. Perform test­ing, col­lect feed­back and it­er­ate.

• Showcase: Complete the re­quire­ments back­log and build a data­base model to align with the val­i­dated pro­to­type.

This ap­proach to prob­lem solv­ing en­sures that the team un­der­stands and has iden­ti­fied the cor­rect prob­lem early on. From there, ideas are tested with users of­ten to fi­nally pro­pose a vi­able so­lu­tion that meets the goals of the pro­ject.

No two soft­ware pro­jects are the same. For this rea­son, the scop­ing process is flex­i­ble to ac­com­mo­date for dif­fer­ent prob­lems, cus­tomers and bud­gets. There are sev­eral fac­tors that im­pact the scop­ing process, the most im­por­tant is the dis­tinc­tion be­tween Greenfield and Brownfield pro­jects. Depending on the pro­ject type, and its spe­cific re­quire­ments, dif­fer­ent ac­tiv­i­ties should be mixed and matched to cre­ate a so­lu­tion dur­ing the scop­ing pe­riod.

Scoping fre­quency

As dis­cussed above, there is a pref­er­ence to­ward 2-5 week scopes to en­cour­age it­er­a­tive de­vel­op­ment and con­tin­ued im­prove­ment. However, gen­er­ally the ini­tial scope tends to be the largest of the pro­ject, as it out­lines the prod­uct roadmap and sets up the first build for the de­liv­ery team.

Beyond the first scope, there are two paths of re-en­ter­ing scope to pre­pare for the next build:

1. A typ­i­cal ap­proach is paus­ing af­ter the com­ple­tion of the first build, defin­ing your next prob­lem state­ment and then scop­ing the next re­quire­ments - al­low­ing de­vel­op­ment to re­sume once the scope has been de­liv­ered.

2. Another ap­proach is to con­cur­rently scope and de­velop, which ben­e­fits the pro­ject by con­tin­u­ing the mo­men­tum. A Product team would start an up­com­ing scope at some point dur­ing the cur­rent build and would aim for de­liv­ery at some point be­fore its com­ple­tion. Timed cor­rectly, this al­lows the de­liv­ery team to sim­ply flow into the next build with­out paus­ing.