MILESTONE PLANNING EXAMPLE
The example presented here corresponds to the development of a milestone plan for a fictitious restaurant chain called RestoLight and is organized around the method’s steps shown in Figure 9. In practice all these activities will be performed by the team using sticky notes and large-sized papers, which will be physically manipulated and drawn upon.
RestoLight, a famous restaurant chain, has asked your company to develop a tablet based order taking systems for its franchises. Following several conversations with its executives, you sketched the notes below and identified the functionality described in Table 2.
- The project must include a beta testing period to validate the app design.
- RestoLight will not accept deployment until a system-wide acceptance test is satisfactorily completed.
- Sign-off will follow satisfactory deployment of the system.
- There must be at least three software releases: one to collect users’ feedback via beta testing, another one to confirm the progress of the system towards the launch date, and the final one to complete the system with minimum risk to the launch date.
- RestoLight is preparing to launch a new menu in June of next year, so it would like the system to be ready at least one month before that.
For its part, your company:
- Cannot start the project until the end of September.
- Will assign four developers to work on the project.
Based on the requirements above and its professional knowledge, the development team produced the Work Breakdown Structure shown in Figure 13, describing its understanding of the project’s scope and the estimated effort required for its execution. As part of the MDAX process, the customer and the team conducted a release-planning session where they agreed on the content for each of the three releases. Release 1 will include all menu browsing, adding and removing items from an order, ordering, clearing an order, adding a tip, paying with card, paying with cash and publishing updates to all devices. Release 2 will include the following user stories: customizing an ordered item, and adding and removing items from the menu. Finally, Release 3 will include paying with loyalty points and modifying menu items.
Step 2.1: After considering what was important to communicate to the customer about the advance of the project, the team chose the milestones listed in Table 3. Beware that the solution is not unequivocal. While there are self-evident milestones like project kick-off, software releases, and the client request for a beta test, others are created by the team, based on its best judgment as to what is important and what is not. The completion criteria associated with each milestone define its meaning and help identify which WIs should be mapped to them.
Steps 2.2: To construct the Milestone Dependency Diagram, we start by organizing the milestones identified in the previous step in what seems like the most logical sequence, and then we identify and connect them using finish-to-finish dependencies. Figure 14 shows one possible Milestone Dependency Diagram for the project. The way to read the diagram is as follows: milestone x cannot be completed until all its direct predecessors have been completed. For example, the platform cannot be made available until the it is selected, and the Beta testing cannot be launched until Release 1 is completed. Notice that the dependency chart says nothing about when the work for it ought to start.
Table 2. Required functionality for the RestoLight Project
|1||As a customer I would like to browse savoiry items in the menu so I can make up my mind about what to order|
|2||As a customer I would like to browse drink items in the menu so I can make up my mind about what to order|
|3||As a customer I would like to browse sweet items in the menu so I can make up my mind about what to order|
|4||As a customer I would like to browse promotions items in the menu so I can make up my mind about what to order|
|5||As a customer I would like to remove a book from my purchase cart if I change my mind about purchasing it|
|6||As a customer I would like to add a menu item to my order so I can order it|
|7||As a customer I would like to remove a menu item from my order if I change my mind|
|8||As a custormer I would like to customize (cooking, ice, no ice, salt, no salt, etc) the items I order so they would be served to my liking|
|9||As a customer I would like to order the chosen items so they would be served to me|
|10||As a customer I would like to clear all items from a order in case I completely change my mind|
|11||As a customer I would like to pay for my order with credit card|
|12||As a customer I would like to pay for my order with cash|
|13||As a customer I would like to pay for my order with loyalty points|
|14||As a customer I would like to add a tip to the check|
|15||As a restaurant manager I would like to add a new item to the menu so it would reflect the latest offerings|
|16||As a restaurant manager I would like to remove an existing item from the menu so it would reflect the latest offerings|
|17||As a restaurant manager I would like to change the details or price of an existing menu item so it would reflect the latest offering|
|18||As a restaurant manager, once I have finished updating the menu, I would like to publish it in all restaurant devices so they reflect the latest offering|
Step 2.3: In this step, we read the milestones in order from the milestone dependency diagram and list them from left to right as headers of the MPM. If two milestones have a similar due date, it doesn’t matter which one you list first, since the sole purpose of the ordering is to increase the matrix’ readability.
Step 2.4: In this step, we assign WIs to their corresponding milestones. Although this tends to be a pretty mechanical process whose value resides on the transparency it brings to the planning process, there are a number of points worth highlighting (see Table 4). The first is that the milestone “Platform Available” has no WI associated with it. This is so because, although the work to select the most adequate tablet is part of the scope of the project, the effort to provision it, is not. The reason to include it as a hard milestone is that it represents a commitment made to the project team by the customer, so they can start developing, and to signal that a delay in fulfilling this promise could affect the completion date of the whole project. The second is the case of the “Refactoring & Feedback” WI, in which a certain number of hours were allocated to Release 2 and others to Release 3. We did not allocate any effort to Release 1, because it was assumed the refactoring would be the result of introducing new functionality and feedback from beta testing in the later releases. There are multiple criteria on how to allocate effort to each milestone. In this case, we thought it would be best to allocate more hours to Release 3 because in it we will remove all technical debt, and we will have to accommodate any changes resulting from beta testing. The third point of interest is the “Browse Menu” WI. In this case, we could have included instead the individual WIs: “Browse Drinks”, “Browse Savoury”, “Browse Sweets” and “Browse Promotions”, but in accordance with the recommendation to list the highest level element that contributes on its entirety to a milestone, we did not which resulted in a simpler matrix. That being said, if one wanted greater visibility of the allocations, listing all individual WIs would be perfectly acceptable as well.