Chases Planning Story

Chase’s Planning Story

If there is one thing Chase has learned over the years, it’s that you can’t build great software without great requirements. To emphasize this, Chase calls a meeting with his entire team along with key stakeholders of Humongous Insurance. During this meeting, Chase talks about how requirements form the foundation for everything that follows. Every estimate and every line of code needs to be derived from good requirements. The team is about to embark upon planning activities, and Chase wants to ensure that requirements, not technology, are their focus because without good requirements, the possibility of producing a good plan is remote. Chase tells his team that a good plan involves the entire team and that he expects everyone to contribute to all areas of their plan as they move forward. Chase also emphasizes that planning isn’t a phase of a projects, it’s an activity throughout the project life cycle. He tells the project team that the initial plan will be the focus of the next few weeks; however, this plan will be reviewed and updated at the end of every iteration right up until the release of their product. Some team members express concern with this approach-they suggest that it will be a waste of time. But Chase convinces them that estimates are only a best guess and that with each subsequent iteration, the guesses will be more accurate.

Chase has a 45-minute train commute every day and has learned to make the best of the commute by focusing on work. To facilitate being able to work on his laptop during his train ride, Chase creates a project workbook in Office Excel that will link to all of the work item queries in Visual Studio Team System he uses every day. This will allow Chase to take work items with him on the train and provide him with the ability to add new work items and modify existing work items while offline. More importantly, when Chase gets back to the office, he will have the ability to synchronize all of his changes with Visual Studio Team System.

To begin the planning process, Chase leads his team through a requirements-gathering workshop in which he brings together his team and a group of people who will ultimately be using the product. Together, they use a whiteboard to brainstorm about the scenarios that the software should provide. At the end of the meeting, Chase works to create Scenario work items in Visual Studio Team System that represent the scenarios that were identified and then assigns these work items to various team members who will be responsible for gathering more information for each scenario.

A week later, after which the team has spent time with their target user representatives to detail each of the scenarios and uncover the many additional quality of service requirements needed by users, such as performance, response time, security, and availability, the team once again comes together to review all of the work in progress and to begin basic estimation and prioritization of the all of the requirements. Chase instructs the team on how to prioritize requirements by using priority buckets and how to perform basic rough order of magnitude estimates on all of the identified scenarios. He also stresses the importance of performing these activities as a group to ensure that everyone’s expectations and understanding are the same.

While the rest of the team is busy detailing requirements, Chase is hard at work creating an initial iteration schedule that was based on the general constraints Chase was given to work with. He knew that he had six months to release a new product. Chase also knew his budget would ultimately determine the size of his team. From this information, Chase began to decompose his timelines into iterations. Chase began by allowing time at the end of the project for stabilization and release management activities. Chase also allocated the first few weeks of the project to focus on requirements and initial planning activities. This left his team with about four months to build and test software. Chase further divided this four-month period into three-week iterations and selected iterations that would focus on delivering interim releases of the product. Chase would then use this skeleton iteration plan to schedule the work required to develop the scenarios his team is working to build.

After the initial iteration plan has been constructed and all scenarios have been identified, prioritized, and given a rough estimate, Chase worked with his team to decompose each of the requirements into tasks. Chase made sure that all types of activities related to building each requirement was taken into account, such as design, coding, testing, build integration, reviews, revisions, and bug fixing. Each of the tasks that were derived from each requirement was stored in Visual Studio Team System as a task work item and was linked to the requirement from which they originated. In addition, each Task work item was given an hourly estimate that was agreed to by the entire team. During the course of this process, many risks were identified that would jeopardize aspects of the project. If teams could not provide an accurate estimate on a task, additional work was scheduled that would allow the team to conduct further work to better understand the underlying requirement, technology, or method to help increase the accuracy of the estimates. Each of the risks were recorded in Visual Studio Team System so that they can be tracked and integrated into the overall schedule of the project.

After all of the tasks and risks have been entered into Visual Studio Team System, Chase worked with his team to schedule all of the work into the skeleton iteration plan he created. Chase made sure that his customer representatives participated in this process so that everyone agreed to the ordering and timing of the requirements delivered by the team. During this process, the team discovered that there were too many requirements for the amount of time and money assigned to the project. With the help of the customer representatives, Chase and his team were able to remove lower-priority requirements from the scope of the project, reflecting their decisions in the State fields of corresponding work items. Chase and his team used Office Excel to assign work items to each of the iterations; however, his project sponsors wanted to see the Gantt chart and work breakdown structure in Office Project. After his team completed assignments of work to each of the iterations, Chase then used Office Project to import the task work items and make the appropriate adjustments to the start and end dates of each of the tasks based on the start and end dates of the iteration they are in to produce the appropriate report for management. Chase ensured that the Office Excel workbook and Office Project file he used were safely stored in the project portal for his Team Project so that they can be used in future iterations when they revisit the plan and need to make adjustments.