Visual Milestone Planning in a Hybrid Development Context

Visual Milestone Pl anning in a hybrid development context Eduardo M iranda [0000-0001-8195-7506] Carnegie Mell on Universit y, Pittsburgh PA 15 213, USA mirandae @ andrew.cmu .edu Abstract. This paper explain s the Visual Milestone Planning (VMP) method us- ing an agile vo cabulary to facili tate its adoptio n by agile pr actitioners as a front end for a hybrid develop ment process. V MP is a visual and collaborativ e plan- ning approach w hich promot es a shared und erstanding of the w ork approach and commitment through the direct manipulati on by team memb ers of the r eified planni ng constructs i nvolved i n the devel opment of the plan. Once th e product backlog has been established and relevant milestones identified, a n ovel construc t called the milestone planning matrix is used to documen t the allocation of prod- uct backlog items to mileston es. The m ilestones due da tes are later dete rmined by grouping stick y notes represe nting the work t o be performed i nto timeboxes called work packages and accommodat ing them on a resou rce and time scal ed scheduling canv as very much as it would be done in a Tetris game. Keywords: Milestone plannin g, Hybrid devel opment, Agile project manage - ment. 1 Introduction Prominen t agile autho rs have lo ng advocated th e need for a pro ject to have an arti fact to guide the wo rk of a team through it. Cohn [1], for examp le, suggests the use of a release pla n, without whi ch “teams move e ndlessly fro m one iteratio n to the next”; Cockburn [2], a dds “a coarse-gra ined projec t plan, possibly created from a pr oject map or a set of stori es and releases to ma ke sure the project is delivering sui table busines s value for suit able expense in a suitable time peri od”; Highsm ith [3], postulat es a Spec- ulate Phas e, in which “a capabil ity and/or feat ure-based rel ease plan to de liver on t he vision is develope d as well as a wave (or milestone) pl an spanni ng seve ral iterat ions used as maj or synchroniz ation and integration points”; and Brech ner [4] wri tes “it’s important t o have a visio n and a plan fo r achieving your project goals. Even crowdsourci ng projects nee d an or ganizing pri nciple and st ructure to al low everyo ne to contribu te toward the shar ed outcome” . Although t hese authors di scuss the cha racteristics t hese plans must sho w, e.g. that the plan must be formulated, not in terms of the tasks t o be performe d but rathe r in terms of the o utcomes the pr oject must del iver and h ow they must be elaborated , e.g. 2 collectivel y by the team and n ot by a solitary projec t manager who late r hands it dow n to it for execu tion, they do not prov ide a method for doing it. This approach to planning wa s first prop osed by Andersen [5] who calle d it Mile- stone Planni ng. In his se minal article, A ndersen defi nes a milest one “as result to be achieved … a descri ption of a condi tion or a state tha t the proj ect should reach by a certain poi nt in time. A mi lestone desc ribes what is to be fulfil led, but not the metho d to fulfil it”. In a subse quent work [6 ], he describes mile stone planni ng as an activity to be perform ed by the gr oup stating “We strongly emphasize the motivational a nd inspi- rational as pects of planning. They are of ten neglect ed in prac tice so that planning be - comes a tedious ch ore carried out on t he project manager’s desk or PC. T his results in a lack of ow nership of the plan by the parties invol ved in the project a nd conseque ntly the plan i s never actively used. This is one re ason for the fa ilure of s o many p rojects”, but also like in the case of t he agile aut hors, he fa iled to pro vide a met hod to construct such plans. Th e gap was a ddressed by Mira nda [7] w ho proposed a pa rticipat ory and visual app roach to construc t milest one plans he cal led the Visua l Milestone Planning (VMP). By their ow n nature, g ood milestone plans are rob ust, compre hensive, easy t o un- derstand, and c onfer great fle xibility in te rms of how to ac hieve the mi lestones, all of which ma kes them a good fit to organize agil e endeavors . This paper c asts the VMP approach i n the conte xt of planni ng a proj ect which will be executed using an agil e approach l ike Scrum. C reating w hat is commonl y define d as a hybri d approach [8]. The execution aspe cts of the project are only c ursory covere d due to page c ount limit s and the inte rested reader is dire cted to [ 9] and [10] for an in- depth treat ment. The rest of the paper is o rganized as follows: S ection 2 de scribes milestone pl ans, Section 3, briefl y describe the execution of th e plan, Section 4 expl ains the proposed method, Se ction 5 provid es a detailed example that illustrates t he use of t he method and serves as v alidation a nd Section 6 pr ovides a summar y and refere nce to the initia l evaluatio n of the metho d. 2 Milestone plans Figure 1 s hows a co nventional milestone plan. As can be obs erved, the plan is conc ise, typicall y confined to a size which w ill allow it to b e grasped at on ce and written u sing a vocabulary stakeh olders can understa nd. The plan comprises the sequence of states the project will go through, from its inceptio n to its successful concl usion, and not the activitie s the team needs t o perform to ac hieve those st ates which will be proposed as work progre sses. For example , the “Design con cept approved ” milestone defin es a state where the pro ject team h as presented an idea that satisfi es the needs of the sp onsor, and she has acquiesced t o it. The plan does not esti pulate how the team will ge t there. Will they show wireframe dia grams to her? Develop hi gh fidelit y protot ypes? Make a Pow- erPoint prese ntation? These issues will cert ainly have to be addresse d by the team , for example duri ng sprint pla nning, but they ha ve no place in t he milestone pl an. The focus o n states r ather than on activi ties results in a more ro bust plan sinc e, in- dependent of what tasks nee d to be performed to get there, whe n and by wh om, it is 3 unlikely, t he project sponsors’ desi re to approve the design conce pt before it is imple- mented, will change. The depende ncies between milestones a re typical ly “Finish t o Finish” rel ations, meaning that i f “Milestone B” depends on “Milest one A”, “Milesto ne B” cannot be completed until “Mil estone A” has b een complete d. Finish to Finish relatio ns are easy to spot and prov ide flexib ility as to when the activities leadi ng to the realization of the milestone coul d start. Milestones cou ld be hard or soft. Hard milestones are milestones, that if not accom- plished b y a set date , lose all or most of i ts value or res ults in severe pena lties. The da te a governme nt resol ution w hich the system un der devel opment is suppose d to addre ss goes into e ffect an d the start of the holida ys shopping sea son are exam ples of har d milestones a project might encounter. S oft milest ones, on the ot her hand, have comple - tion dates t hat result fr om the plan ning process. T hey might be associated wi th penalti es or other lia bilities afte r a stateme nt of work is ag reed, but in p rinciple a re discretio nary. Fig. 1. A typical milestone plan sh owing due date s, responsibilities and milestones ’ descriptions Miranda [1 0], supplement ed Andersen’ s original technique, wi th the conce pt of “Work Pac kages Sche dule” (s ee Figure 2). A Work Pac kages Sc hedule consi sts of a number of timebox es within w hich all the work associated with a g iven miles tone, called its w ork packag e, will have to be executed for the plan to hold. The pu rpose of the Work Pack ages Schedule i s twofold: 1) to dete rmine the earlie st day by which a 4 milestone ca n be compl eted in the c ontext o f other pr oject work that might n eed to be performe d, and 2) t o drive the sc heduling of work durin g project execution . Within the con straints imposed b y the hard milestones ’ due dates and the depe nden- cies identi fied in the pla n, the Work Pack ages Schedule will be decided by the team according to its technical, bu siness and staffing strategies, such as: this needs to b e done before that, do as much work as possible at the onset , start slow to mini mize risk and then agg ressively ra mp up, main tain a co nstant work force, work must be c ompleted within six months, do not use more t han five peopl e, and so on. In const ructing it , we will assume, the distribut ion of c ompetencies in the t eam matches the work’s needs. This is a sensible assumpti on in an agile contex t which assumes either generalists or balanced, c ross-func tional, te ams. In cases whe re this ass umption woul d not hold, it would be possible t o break the resource di mension int o competenc y lanes and a ssign the correspondi ng effort to each lane. The same approach could be used to scale up the method to be used in pro jects with multiple teams. Fig. 2. Work Packages Sch edule. This repres ents one poss ible arrangem ent of work pa ckages corresponding to the m ilestone plan in Figure 1. Each shad ed area correspond s to the work ass o- ciated with th e milestone imme diately to its ri ght. The reso urce-time frame en closing the work package is its timeb ox. During iteration 1 and part of i teration 2, on e team member will wo rk on UX Design and another in the selection of infras tructure. Other team member s can help as needed. From iteration 2 to 6, the team will mainly work on the items included in the first release; from iteration 7 to 9, the team will work o n the features included in the s econd releas e and in Beta testing. Adapted from [7] 3 Executing the plan In the cour se of the projec t, the team pro gressively refines items in the backlo g to meet their def inition of re ady and dec omposes them i nto the tasks necessary for its rea lization during t he iterat ion/spr int planni ng meeting , as dic tated by the timeb oxes depi cted by the Work Packa ges Schedule inste ad of the biwee kly concerns o f the product owne r. As developm ent progresse s, the plan is up dated to refle ct new circumst ances arising from the work complete d or from change s in the proje ct context, bu t since mileston es 5 are basically state s or goals to be attained, and the pla n does not speci fy when tasks must begin , how l ong they s hould take, nor who sho uld perform t hem, it tends to be pretty sta ble. 4 The Visual Milestone Pl anning (VMP) Method Figure 3 de picts t he VMP Method. T he first step in the pr ocess is to cre ate a product backlog de fining t he project sco pe. Each backlog item i n it wil l have associat ed the estimated effort re quired for its realizati on. These estimates will be later use d to estab- lish the timeboxes i n which the antic ipated work could be performed. VMP propose s the adopti on of a hierar chical produc t backlog, see Figure 4, which is an enumerat ion of all the outputs to be delivere d to the cu stomer to meet the project objectives: fun ctionality, d ocumentation, infrastructure, gadget s, and services, dec om- posed int o smaller ch unks, un til they reac h the use r story l evel, which defines backlog items that c an be complete d in a single iter ation. Techni cal stories are work th e team needs to perfo rm but unlike user stories do not have a direct user value counte rpart. The hierar chical natu re of the b acklog faci litates the comprehension of the p roject’s s cope and support s the prog ressive refineme nt of the i tems identifi ed, their esti mation and t he collectiv e assignment to mileston es. The structur e proposed is compatib le with the def- inition of bac klog posited now adays by most practi tioners and tools, e.g. S AFe (epics , capabilitie s, featur es, stories), Jira (initiativ es, epics, sto ries), Azure ( epics, featu res, stories), Rubin (epics, t hemes, stories). Since the backlog forms t he basis for planning , it cannot be open en ded in t he sense of a backlog in a tr aditional ag ile project. Balancing pred ictability with progress ive re- finement r equires the creation of planni ng aggregates for w hich a bu dgetary allow - ance will be made, in the understa nding that wh en the ti me comes and th ey are de- fined, either we will circumsc ribe our level of ambition to t he available budget, or the plan will need to be revisit ed. A project who se final outc ome is not well defined co uld be scoped in te rms of learn- ing activities suc h as running a design sprint and planning p ackages that ha ve a definite purpose, e. g. Release 1, R elease 2, etc., an d budget, but whose exact content ha s not yet been decided. The second ste p in the pro cess is th e definitio n of milestones. Mi lestones are chosen to signal the attainme nt of a major ac hievement, the delivery of key compone nts or assemblies, the completion of important p rocess steps or to mark a commitmen t made to the team , e.g., a cust omer makes proprietary e quipment or t echnology req uired by the proje ct available to the team. No tice that in the diagram th ere are arrow s back and forth betwee n steps 1 and 2. This is so because although th e product backl og will nor- mally inform the choice of milestones, sometimes the est ablishment of a pa rticular milestone might result in the creation of ne w backlog ite ms that must b e incorporat ed to it or leads to its rearra ngement. 6 In step 3, we document the depende ncies existing bet ween milestones b y means of the Milestone Depe ndency Diagra m. Notice the diagram c ontains no dates, exc ept for those ass ociated with hard milest ones. This i s to permit t he considerati on of different staffing an d timing stra tegies l ater in the proces s. The process fo r the creati on of the Milestone Dependency Di agram starts with the writi ng of each identifie d milestone name on a sticky note1 and its quick order ing, according to thei r most obvious sequen ce of completi on, followed by a discussion o f specific de pendencies, t he connecti ng of the correspon ding milest ones, and, i f necessary , the re ordering of the o riginal se quence. The depende ncies betwee n milestones a re finish-to -finish, si nce these a re more obvious than the most common fi nish-to-sta rt and g ive a lot of f lexibility on when to start work- ing on a work package. A simpl e example of a finish-to-fi nish dependen cy is that be- tween codin g and testing . One coul d start wr iting test ca ses before c oding begi ns, but one cannot finish i t until the coding is done. In t he fourt h step, eac h cell in t he header row of the Milest one Planning Matrix is po pulated with the name of the milestones . 1 Although it is pos sible to do this us ing digit al tools , it is reco mmended at least i nitially to do i t this way because VMP prom otes involve ment an d commitment, through the reification of the planning c onstructs: work pack ages, milestones a nd schedules emplo yed in the planning pro - cess and their direct manipulation by the tea m members who colle ctively create th e plan. Fig. 3. Visual Milestone Plannin g Method 7 Although no t strictly req uired by the pr ocess, listin g them chronolo gically from l eft to right greatly contributes to the mat rix readabil ity and ease of work. In step 5, back log items are associ ated with t he milestones they help realize vi a the body of t he Milestone Planning Matrix. See Figure 5. T he associati on is infor med by the milestone definition , for exampl e, a “Release 1” milestone wo uld be associ ated with all backlog items included in the sa id release. The asso ciation is don e by labeling a row in the plan ning matri x with th e name of the t op-most backl og item w hose descenda nts all contribu te to the sam e milestone and reco rding the effort re quired by it at the in ter- section of the row wi th the column co rresponding to the mileston e with whi ch the item is being asso ciated. A milestone can have multiple backlog items asso ciated with it. In most cases, bac klog items would be a ssociated with a single mile stone in its en tirety; there are, however, a circ umstances like planning packa ges or integrative efforts where it is conv enient to al locate fr actions of th e total effor t required by the item to multiple milestones. Fig. 4. A hierarchical product backlog and its re lation to the iterati on or sprint back- log In step 6, t he team will black out kn own non-wor king periods such as the holidays, trainin g, and ma ndatory vac ations, si nce in principle , there would be n o work car ried out during that time . In step 7, the te am will mark all the hard milestone s in the work pac kages schedulin g canvas. Hard milestones w ill act as anc hor points for t he plan. 8 In steps 8, 9 an d 10, the team iterativ ely builds the Work Package s Schedule, see Figure 6, b y posting st icky notes on an e mpty spac e in the work package scheduli ng canvas, start ing first wi th the work cor responding to the process ce remonies, fol lowing with the wor k correspon ding to the ha rd milestones a nd finally wi th that of the soft milestones. Si nce the pl anning in volves the p hysical posi tioning of st icky notes on the canvas, the re must be a correspon dence between t he work hour s repres ented by each note and t he canvas’ physi cal dimensi ons. If for e xample, we choose a 3”x 3” st icky note to re present 40 hours of w ork, each th ree inches o n the tim e axis of the canvas will corresp ond to a week and three inches in the resources ax is will corr espond to a full time equi valent (F TE) resour ce. Had w e chosen a lower g ranularity, e.g., a sticky not e to represe nt 150 hours o f work, whi ch woul d be usef ul in the case of a l arger proj ect, each three in ches on the ti me axis would corr espond to a mo nth instead of a we ek. One could rip off st icky notes t o express fracti ons of effo rt or tim e, but t his shoul d be hardl y necessa ry given the resolutio n of the plan. Fig. 5. Milestone Planning Matrix In step 11, the pla n is completed by spruci ng the milest one sequence diagra m, as- signing due da tes to the soft milest ones, adding resp onsibili ty information, an d inte- grating all of them in a c ommon docume nt. The app roximate due date for eac h soft milestone is fou nd by looking in the Work Pac kages Schedu le for the d ate aligne d with the right e dge of the ti me box associa ted with the mil estone. Ha rd milesto nes have, by definit ion, a set date. 9 Fig. 6. Iterative constru ction of the Wo rk Packag es Schedule us ing sticky notes to represent the effort required t o realize each milestone 5 Detailed example This sect ion provi des a step-b y-step acc ount of the applicati on of the process in f igure 3 to the cr eation of the milesto ne plan in f igure 1. Imagine you r company is bidding in a c ontract to develop a n ecommerce site for a small book publisher a nd after some discussion with your c ustomer you sketched t he following no tes: 1. Custome r wants to inclu de a beta test ing peri od to validate t he site design. 2. Customer will no t accept deployment unti l a system wide acceptan ce test is satisfac- torily co mpleted. 3. Customer sign-o ff will follow satisfactory deployment of the system. 4. Customer would lik e to have at leas t three softwar e releases: one to c ollect users’ feedback via b eta testing, anot her one to confirm the pro gress of the system toward s the launch date and the fina l one to complet e the system with min imum risk to the launch date . 5. In the first release sh e would like to inc lude the following user stories: Category List (CL), B ook Details ( BD), Add to Ca rt (AC), Che ck-Out (CO) and the Data B ase epic 6. In the second release , the Category Book List (CBL), Remov e from Cart (RC) and Shipping Method (S M) 7. The cont ent of the third r elease i s not kno wn at this time, but the cust omer would like to reserve a sig nificant num ber of hours to inco rporate the feedback res ulting 10 from bet a testing an d introduce other user storie s that might emerge during develop- ment 8. The customer is prep aring to laun ch its busin ess around the b eginning of M ay of next year so s he would like t he system to be rea dy at least one mo nth before t hat. For its part, your company: 9. Cannot start t he project u ntil the end o f September a nd has only fo ur developers t o work on the proj ect. 10. To minimize the risk of rework , it does not plan to star t programming until the in- frastructure is select ed and the user interface and informa tion archi tecture desig n are well underwa y. 5.1 Step 1 Based on the requirements ab ove and it s professional knowledge the developme nt team created the bac klog shown i n Figure 7 desc ribing the ir understan ding of the pr oject’s scope of work and the estima ted effort required for i ts executi on. The req uired soft ware capabil ities were group ed into four epics: Bro wsing, Buying and Data Base to incr ease the read ability of the backlog as the team f elt a groupin g based on Rele ases would have hindered the com prehensio n of system func tionalit y. UX design, Infrast ructure Selec- tion, Beta and Acceptanc e testing are technic al storie s that could ha ve been ma de part of the Websit e Software deli verable, but whi ch the team chose to p ut at the first level of the bac klog to hi ghlight its understandi ng of the cust omer wis hes. After s ome dis- cussion abou t how many hours to re serve for th e final rele ase, the tea m decided to al- locate 450 hours since this was compatible with the team’s reso urce availabi lity, the customer sc hedule an d provided ample time to inc orporate feedback a nd complet e a few, yet undi scovered, fea tures . Fig. 7. Hierarchical ba cklog for the A mazonLight project 11 5.2 S tep 2 After obt aining concurr ence for th e backlog fro m the sponsor, the team started choos ing relevant milestones producing the list in Tabl e 1. Bewa re the solutio n is not u nequivo- cal. While there are self-evident milestones li ke project ki ck-off, softwa re releases and the custome r request for a beta te st, others are created by the team based on it s best judgment as to what is important and what is not. T he completion cri teria associated with each mil estone defines its meani ng and helps ide ntify whic h backlog i tems should be mapped onto them. The mi lestones are organized i n what seems li ke the most l ogical sequence t o make the list easier to und erstand an d search for. 5.3 Step 3 The team co nstructs the Miles tone Depende ncy Diagram by organizi ng the milesto nes identifi ed in the previo us step in what seems lik e the most log ical sequence, and th en by connecti ng them using fini sh-to-fini sh dependencies. Not ice that the depe ndency diagram say s nothing ab out when the wo rk for it ough t to start. We will addr ess this in step 10. 5.4 Step 4 In this step, the team reads th e Milestone Dep endency Diagr am in its most natura l sounding ord er, writing the mileston es names from left to righ t as headers of the MPM. If two milesto nes have a simi lar due date , it doesn’t matter whi ch one is listed first, since the so le purpose of the ordering is to increas e the matrix’ readability . 5.5 Step 5 During t his step , the team asso ciates th e backlog it ems with th eir corre sponding mil e- stones. This is a rather mec hanical activi ty whose value re sides on the visi bility it brings to the planni ng process. As discusse d above, a backl og item can be as sociated w ith more than one milestone as s hown by rows 1.a, 1.d, 1.e and 1 .c.5 in Fig ure 8. While this techniqu e relieves us from crea ting backlo g items just for the sake of having each item map to a single mileston e, abusing it obscures the mapping , for what it should be used sparingl y. Milestone “C loud Inf rastructure A vailable” has no backlog it em asso- ciated wit h it, because althoug h the work to select the inf rastructure is part of the scop e of the proj ect, the ef fort to pro vision it, is not. The reas on to include it as a mi lestone is that it repr esents a comm itment made to the pro ject team by the cu stomer so it could beta test the system and to signal tha t a delay in fu lfilling th is promise cou ld affect i ts completion date. In the ca se of project ma nageme nt, item 1.g, the effort was not all o- cated to any milestone to be later spread over the life -span of the pro ject accordi ng to a uniform p rofile. 12 Table 1. Potential milestones for th e AmazonLigh t project Milestone Rationale (from notes abo ve ) Hard date Com p letion criteria Project kick-off 9 October this yea r Development team assembled , meet- ing with project sponsor concluded Design concept approve d 10 Information arch itecture and UI de- signed a nd approv ed by sponsor Infrastructure se- lected 10 Cloud provider s elected. Consid er AWS, Azure, G oogle Cloud and 2 oth- ers Design com- p lete d Proposed by team Feedback from sponsor in corporated into desi g n Cloud infrastru c- ture available Proposed b y team Cloud prod uction environ ment availa- b le Release 1: CL, BD, AC, CO, Data Base 4, 5 Indicated functionali ty is ready and tested at 90% coverage and working in production con figuration. N o broken menus or li nks Beta testin g launched 1 Release 1 software made availab le to beta users. User behavior hy potheses defined. We bsite instrument ation workin g Release 2: CBL, RC, SM 4, 6 Indicated functionali ty is ready and tested at 90% coverage and working in p roduction config uration Beta testin g re- sults reviewe d 1 All insights arising from th e beta tes t- ing disposed Release 3: Emer - gent fe atures 7 Reserved effort to implem ent changes suggested by the beta testing and un- known feature s Acceptance test- ing procedure approved 2 Acceptanc e test suite ap proved by sponsor. Inclu des at least on e positive , one negative and one invalid test case for each functi onalit y Acceptance test com p lete d 2 All acceptance test passed w ith no ob- j ection from s p onso r System de ployed 8 April next year All functionality ru nning in production environment, op erators trained. S ys- tem must run for at least 15 cons ecu- tive days with out a fault attributable to software Customer si g n-of f 3 Customer accepts ownership of t he software Project closed 8 May next yea r Project postmortem executed; all rec- ords archive d 5.6 Step 6 The team marks t he Christmas an d New Year weeks as a non-working pe riod. 13 5.7 Step 7 Beside its start and end, the proj ect contains only one hard milestone, the “ System De- ployed” mil estone set for the beginning of Apri l. As by definition , a suc cessful plan must satisfy i ts hard mil estones, we start by marking t hem on th e Work Pac kage Sche d- ule canvas as they would co nstrain how the wo rk could be orga nized. 5.8 Steps 8, 9 & 10 The goal of these steps is to e stablish a window of oppo rtunity in which th e work stated by each work package must be executed . To do this, t he team will label or some how tag as many sti cky notes as ne eded to cover t he effort req uired by ea ch work package and accommodat e them in an approp riate empty space on t he Work Packa ge Schedul e canvas. T he tagging is importa nt to identi fy which work corre sponds t o what, so t hat is possible t o rearrange it i f necessary . The team st arts by acc ommodati ng the effo rt cor- respond ing to all cross- cutting work packages, then t hat correspond ing to the work packages conne cted to hard milestones and finally those corresponding t o the rest of the work package s in the orde r dictated by th e milestones’ dependencies. If necessary, the team might in tersperse buff ers to protect milesto nes deemed critic al. Figure 2 shows a styli zed version of a possi ble plan for the Amazo nLight project. Notice that due to the holiday peri od, extendin g from late December to e arly January the effort for the Release 1 work package was spread over two month s by splitting t he sticky note s. As shown by th e figure, with th e constrain ts put on the availab le resour ces – three develop ers and a project manager – it was not possible to deploy the system by April as the custome r wanted, so aft er negotiati ons it was decide d to move the milestone to the beginni ng of May. Othe r alternatives could have been to incorpora te more re - sources, reorga nize the work, e.g. re lax the conditi on of not doing deve lopment work before the design concept has been approved, o r renegotiate the sco pe. 5.9 S tep 11 In Ste p 11, the mileston e plan is comple ted by reading from the Work Package S ched- ule the appr oximate dat e in which th e work associa ted with each m ilestone w ill be completed a nd assigning i t as the due date for the milest one. 6 Summary In this pape r, we explai ned how the V MP method i ntroduced i n [7] can be used i n an agile con text. The method is based on the man ipulation of reif ied constru cts such as work packag es and mile stones in a coll ective practice , which prom otes shared un der- standing and buy -in into the plan. The VMP meth od has evolved over three years of classroom and consultin g experience an d has been put into practi ce in mid-si zed cap- stone projec ts, 2,500 to 5,000 pers on-hours long, a nd at two industrial organizations . It 14 has also been ev aluated for us ability using th e Process and Prac tice Usability Model [15]. Althoug h further experie nce and assessmen ts are required, its init ial evaluatio n and observat ions point in t he direc tion of the method’s ease of use and its value i n organiz - ing a proje ct. Fig. 8. Milestone Pl anning Matrix for the AmazonL ight project References [1] M. Cohn, A gile Estimat ing and Plan ning, Uppe r Saddle R iver: Pre ntice-Hal l, 2006. [2] A. Cockburn, Crys tal Clea r A Human- Powered Met hodology F or Small Tea ms, Upper Saddle River: Addison W esley, 2004. 15 [3] J. Highsmith, Agile Proj ect Manage ment, 2nd Edition, Upper Sad dle River: Addison-Wesle y, 2010. [4] E. Brechne r, Agile Proj ect Management wi th Kanban. [5] E. Andersen, "Warni ng: activity pl anning is haza rdous to your proj ect's health!," Internatio nal Journ al of Pr oject Manage ment, pp. 89 - 94, 1996. [6] E. Andersen, K. Grude an d T. Haug, Goal Direc ted Proje ct Management , 4th., London: Ko g an Pa g e, 2009. [7] E. Miranda, " Milestone Pl anning: A P articipato ry and Vis ual Approach ," J ournal of Modern Projec t Management, vol. 7, no. 2, 2019. [8] M . e. a. K uhrmann, "H ybrid Softwa re Developme nt Appr oaches in Prac tice: A European Pers pective," IEEE Software, vol. 36, no. 4, 2019. [9] E. Miranda, "Mileston e Driven Agile Executio n," in Balanc ing Agile and D isciplined E ngineerin g and Manage ment Appr oaches for IT Serv ices and Software Products , IGI Global, 2021. [10] E. Miranda, "Bridgi ng the Gap Between A gility and Planning," PM World J ournal, 11 2020. [11] D. Fontde vila, M. Gene ro and A. Ol iveros, "Towar ds a Usabil ity Model f or Softwar e Development Process and Pr actice," in Prod uct-Focused S oftware Process Improvement. PROF ES 2017 , 2017 .