The previous two chapters explain the essence of CUP as a process. In this chapter, we explore how to execute that process. This section will discuss in detail how to put CUP into practice.
Task Log
The Task Log is what drives the entire product development lifecycle. It is a collection of all the requirements (user stories), individual programming tasks, bugs, code review tickets and change requests for a project. It also includes any issues, clarifications, suggestions, etc., that may arise during the course of a project. It’s a pipeline of tasks that feeds into the CUP cycles that drive the execution of the project. The Task Log contains information about all tasks that have been created for the project irrespective of their current status.
A Market Requirements document identifies the overall product positioning and high-level roadmap of the product over several releases. For the release at hand, a high level Product Requirements Document will be produced that includes screen mockups and high-level use cases. The Product Requirements Document will drive the product development for the current release.
Key points to remember while managing tasks in the Task Log include:
- Identify all the high level requirements from Product Requirements Document (PRD) and add them to the task log. This is an iterative process by itself. The PRD is continually updated/refined as user stories get collected.
- Define overall framework (and design patterns to be used, if any) that will address the short term and long-term needs of the business. Create tasks to implement the same. These tasks need to be planned before implementing individual functionality.
- As part of the solution, third party packages are likely to be utilized. Thus, for software that requires significant capital or development investment and holds some project risk, a technology or product selection process may be required. Create tasks to identify and develop proof-of-concept code.
- Decompose tasks further before assigning them to individual team members prior to each CUP cycle or during the preparation meeting. Typically, each requirement gets broken into:
a. Creating user stories and associated wire frames/HTML mockups
b. Identify test cases that will exercise the requirements
c. Design
d. Code (different tiers if it is a n-tier application)
e. Unit-test
Each of the above tasks can be taken up in the same iteration or can span multiple iterations. - Identify reusable components and implement them first. These components tend to be independent and are therefore relatively easy to manage.
- Identify tasks to manage builds, deployments and other project infrastructure support required and add them to the Task Log.
Dashboard
CUP recommends setting up a Project Dashboard to manage release plans and individual CUP cycles. The dashboard provides a high level overview of the project status. It should be a very carefully designed view/report of the Task Log that provides a lot of useful information about the project to all stakeholders (Project Manager, Client, Developers, CTO) at any point of time. It should contain information about Total Tasks, Completed Tasks, Tasks In-Work, Newly Added Tasks, Estimated Time for the tasks and Actual Time taken to complete the tasks.
Cycle End Date - This column shows the end date for a development cycle.
Completed - This column displays the number of completed tasks in a development cycle.
Total Completed - This is the running total of all the tasks that have been completed up until the current development cycle.
"The Total Completed figure gives an idea as to how many tasks are pending completion."
Estimated Hours - The Estimated Hours figure is the sum of the estimated hours for all tasks in a development cycle. This will provide quick information on whether the development cycle is fully loaded, lightly loaded or overloaded. For instance, for a 6-member team, a typical development cycle should show around 180-200 estimated hours assuming 5-10 hrs per week goes in meetings, discussions etc. that are not accounted for in the Project Tracker.
Ideal Hours Completed - Ideal Hours are the actual hours taken to complete the tasks in that development cycle. This needs to be entered by the developer on completion of the task. The sum total of actual hours spent in completing all the tasks in a development cycle is shown under this head.
"The difference between the “Ideal Hours” and “Estimated Hours” will provide information on whether the tasks are getting completed in time (i.e. whether the development cycle is on schedule). "
In-work - All tasks assigned to a development cycle show up under this head. In-work here does not mean the tasks are being currently worked on. It just means that they are planned for completion in that development cycle.
Newly Added - Newly Added displays the number of tasks that were added during a development cycle.
" Tasks newly added during the course of a development cycle are not automatically taken up for execution in that cycle. These tasks have to go through the normal task allocation exercise before someone works on them."
Total Tasks - Total Task shows the sum total of all the tasks in the project.
When updating the Actual Time, care must be taken not to reset the total time on that task to date. For example, a developer has updated a task with Actual Time set to 8 Hrs. Subsequently another developer works on that task further and spends another 6 hours. In this case the second developer should set the Actual Time to 14 Hrs and not 6 Hrs. That is, Actual Time should always show the aggregate amount of time spent on the task so far.
The project velocity can be computed from In-work and Completed tasks and is helpful in planning subsequent iterations. This, along with Estimated Hours and Ideal Hours completed, will provide a measure of the productivity of the team. The team may be successful in completing all the tasks in that iteration but still the ideal hours completed may be significantly higher than estimated hours. What this tells the development manager is that the team is not estimating tasks properly and is working overtime to finish all the tasks. This is not a good sign. It will become hard to predict whether the project can be completed on time. Once things become more predictable, the development manager can make any necessary changes to subsequent iterations with a high degree of confidence in the impact to the overall release plan. Predictability, therefore, leads to adaptability.
‘Newly Added’ will provide information in-terms of change requests that are coming in. In an ideal scenario, this number will be high during the start of the development (tasks are getting added and iteration plan, which is getting finalized) and should go down dramatically as we get closer to the release date. There will be a significant impact on the project timelines if this count remains high, an indication of product instability.
CUP cycle
Each individual cycle involves the following: A preparation meeting, daily status updates, and the acceptance meeting at the end of the cycle.
Preparation Meeting
At the start of every CUP cycle the team will have a meeting (at a predetermined time) to discuss and finalize the plan for the current cycle. This meeting is called Preparation Meeting. The goals of the preparation meeting are:
- Discuss and identify the tasks that should be taken up in the current cycle. This includes the new tasks that are yet to be taken up as well as incomplete tasks from earlier development cycles.
- Identify the test cases for each task so that the expectations are clearly set as to what needs to be done for the task to be accepted as complete.
- Allocate tasks to team members. Every team member is typically assigned 35 hours of work per week . If the team is the initial stages of a project, task allocation may require more analysis and discussion. But if the project has already completed several iterations and things are going smoothly, a team may not require more than 5 hrs (per team member) per week for discussions etc. For example a 6-member team will plan to complete 6 * 35 = 210 hours of work per week. That is, after the tasks have been allocated to team members one should see the estimated hours for the CUP cycle to be in the range of 420 Hrs (assuming it’s a 2-week CUP cycle).
Daily Status Update
As part of CUP, the team meets everyday for about 15 minutes to review the status and briefly go over the tasks that the team would be taking up next. The purpose of the meeting is to track day-to-day progress and to keep the entire team updated of the project status.
"Communication among the entire team is the purpose of the status update meeting. A status meeting every morning is used to communicate problems, solutions, and promote team focus. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each. Issues, if any, that are brought up during the status meeting will be noted and discussed separately with those who are actually needed and will contribute. This avoids wasting everybody’s time on discussions that concern only one or two team members. The team members should be able to report daily status in a format that can be viewed by the management. Also, there must be a way to track action items that will come out of the daily meetings"
Acceptance Meeting
At the end of the CUP cycle, there will be a User Acceptance meeting. The purpose of the acceptance meeting is to verify the tasks that are completed in the current development cycle and to ensure the goal of the CUP cycle was successfully met. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release.
Code review should be conducted as part of the Acceptance Test once every CUP cycle. "The user acceptance meeting will be lead by someone from the client side. Acceptance tests should be automated so they can be run often."