This chapter is from the book
This chapter is from the book
This chapter is from the book
11.4 Realization with ClearQuest
In section 11.2, "Agile and Scrum in a Nutshell," we described the Agile process and the Scrum in particular. Unlike Rational Team Concert, which has a built-in process template to support Scrum, ClearQuest does not have an Agile built-in schema. In this section we shall explain how to build a schema to support Agile projects. Reading the process description in section 11.2, we can identify data objects and workflow scenarios. Now let us take out the data objects from the description. These are
- Request
- Product backlog of requests
- Sprint
- Activity
- Sprint backlog of activities
- Team
- Iteration
Let's discuss each of these data objects a bit more.
- A request (or CR or any other name that may fit your environment) is realized by a state-based record type. We shall describe the fields of this record type in the next section, but one important field should be the RequestType. Types could be Defect, Enhancement, Feature, Story, Test Case, and so on. Another important field is Priority; the team will select Requests to implement in the iteration based mainly on priority.
- The product backlog of requests and sprint backlog of activities are lists of work items. We do not need to create a special object for these; the reason is that the logs will be realized with queries whose result set is the backlog. The project backlog is a query on the Request record type that filters all of the analyzed requests (ready to be selected for the sprint), sorted by priority. The sprint backlog is a query on the Activity record type that filters all of the opened activities (not completed) that are referenced from a specific sprint, sorted by priority.
- A sprint is realized by a state-based record type. This record type will have fields of type Reference_List to the Requests and the Activity record types, and fields of type Reference to the Team and Project record types.
- An activity (or task or work item or any other name that may fit your environment) is realized by a state-based record type. As stakeholder requests are usually high-level and nontechnical, the team will break down requests into activities. Each activity will be assigned to a team member.
- The team is realized by a stateless record type. The Team record type contains a list of team members, specific roles in the team such as Team Leader, and users having a role.
- Iteration is realized by a stateless record type. The Iteration record type contains the iteration name, the start date, and the end date.
The record types and their relationships are described in Figure 11.15.
)
Figure 11.15 Entities relation diagram for the Scrum schema
We have realized some of the data objects with state-based record types and some with stateless record types, and we have realized the product backlog and the sprint backlog with queries.
11.4.1 Required Data
In this section we describe the fields for each record type that are essential for the solution. It is assumed that each implementation will include additional fields based on products developed, organizational culture, regulations, and other considerations.
Table 11.1 describes the suggested fields for the Request record type.
Table 11.1. Request Suggested Fields
|
Field Name |
Field Type |
Comments |
|
Headline |
Short_String |
|
|
Description |
Multiline_String |
|
|
CR_Type |
Short_String |
Closed choice list of request types |
|
Priority |
Short_String |
|
|
Requestor |
Reference |
Reference to the user submitting the request |
|
RequestForProject |
Reference |
Reference to the project record (optional) |
|
Activities |
Reference_List |
List of the activities this request breaks down to |
|
Iteration |
Reference |
Reference to the Iteration record |
|
EstimatedEffort |
Integer |
Estimated effort in hours to deliver the request; mandatory in the analysis |
Figure 11.16 is a screen shot of the Request record, with several of the fields listed in Table 11.1.
)
Figure 11.16 Request record: main tab
Table 11.2 describes the suggested fields of the Sprint record type.
Table 11.2. Sprint Suggested Fields
|
Field Name |
Field Type |
Comments |
|
Headline |
Short_String |
|
|
Description |
Multiline_String |
|
|
Iteration |
Reference |
Reference to the Iteration record |
|
StartDate |
Display only, derived from Iteration. StartDate |
|
|
EndDate |
Display only, derived from Iteration. EndDate |
|
|
Requests |
Reference_List |
Reference to the Request record; optionally include back reference |
|
Activities |
Reference_List |
List of the activities this sprint breaks down to |
|
Team |
Reference |
Reference to the Team record |
|
Review |
Multiline_String |
Figure 11.17 displays the Sprint record main tab; it shows the sprint details, the responsible team, iteration name, end date, and other information. You can see the list of requests that will be realized by the team in this sprint, in this case one new feature to develop and one defect to fix.
)
Figure 11.17 Sprint record: main tab
Table 11.3 describes the suggested fields of the Activity record type.
Table 11.3. Activity Suggested Fields
|
Field Name |
Field Type |
Comments |
|
Headline |
Short_String |
|
|
Description |
Multiline_String |
|
|
ActivityType |
Short_String |
Closed choice list of work items/activity types |
|
Priority |
Short_String |
|
|
Owner |
Reference |
Reference to the user who is the solution provider |
|
DueDate |
Date_Time |
Optional |
|
ResolutionDescription |
Multiline_String |
|
|
ActualDate |
Date_Time |
Optional |
|
EstimatedEffort |
Integer |
Estimated effort in hours to deliver the request; mandatory in the analysis |
|
ActualEffort |
Integer |
Actual effort in hours (optional) |
|
UnitTest |
Short_String |
Unit test name; may be an automated script name |
Figure 11.18 is a screen shot of the Activity record main tab, with several of the fields listed in Table 11.3.
)
Figure 11.18 Activity record: main tab
Figure 11.19 displays the Activities tab in a Sprint record. The team has created five activities of different types, to realize the two requests that are shown in the Requests field.
)
Figure 11.19 Activities and Requests related to a sprint
We have seen in this section the record types and the fields that construct the Scrum schema.
11.4.2 Understanding the Workflows of Each Record Type
After creating the three state-based records types and the fields in each one, we need to define the state machine for each record type. In the next section we describe the workflow for each record type.
11.4.2.1 Request
The workflow for the Request record type depends a lot on the organization, the stakeholders, and the regulations enforced. We propose the flow shown in Figure 11.20.
)
Figure 11.20 The Request record type workflow
The Request is submitted to the New state and analyzed to identify feasibility, effort, priority, possible impacts, risks, and so on. After it is analyzed and priority is given by the stakeholders, it can be picked by a team to be developed in a sprint. At the end of the sprint during the Retrospective (review meeting) the deliverables are evaluated. If the deliverables are found to meet the stakeholder request and have the desired quality, the Request can be moved to the Delivered state.
In some cases a Request can be moved from the New state directly to the InSprint state, for example, in the case of a defect or a request submitted by the team. In either case the Request must get a priority value by the stakeholder.
11.4.2.2 Activity
The workflow for the Activity record type is similar to the CMBaseActivity record type of the UCM package. We suggest that this record type be integrated with your version control system. If you are using ClearCase, add the UCM package to the schema and enable the Activity record type to the UCM package. The Request and the Sprint record types should not be UCM-enabled because artifact changes are controlled with the Activity record.
The state machine includes four consecutive states: Waiting, Ready, Active, and Complete (see Figure 11.21).
)
Figure 11.21 The Activity record type workflow
11.4.2.3 Sprint
The Sprint record type is used for project management as explained in the previous section. During the sprint planning meeting (or before) the record is created and its state is Submitted. When the sprint starts (the sprint iteration start date is reached), the team performs the action StartSprint which moves the record to the state InSprint. When the sprint ends (the sprint iteration end date is reached) and during the sprint Retrospective meeting the team performs the action Close, which moves the record to the state Closed. So the Sprint record type has three consecutive states: Submitted, InSprint, and Closed (see Figure 11.22).
)
Figure 11.22 The Sprint record type workflow
In this section we have described the suggested workflow for each of the record types that construct the Scrum schema.
11.4.3 Understanding Metrics in Agile Development
We discussed metrics in detail in Chapter 9, "Metrics and Governance"; we include here just a few words on metrics in Agile projects. Metrics measure data of direct business value to the organization. In the repetitive cycles of Agile projects, improvement can bring value, and to improve we need to measure. Working with ClearQuest, we can measure by means of charts and reports provided by the tool.
Figure 11.23 is a screen shot of the ClearQuest client displaying some typical queries and charts for Scrum projects in the workspace. The executed chart shows Planned Effort, and it displays the estimated effort of requests in each iteration.
)
Figure 11.23 Planned Effort for Iteration chart
The "classic" release burndown charts and velocity charts cannot be created with the ClearQuest chart wizard, but you can create reports and distribution charts that display the closed activities per iteration, or the actual/estimated effort of activities in an iteration, which will provide similar information. Also, using tools such as Rational Insight will allow you to present burndown and velocity charts.