rup iteration planning - ibm · rup iteration planning anthony crain ibm 12 jul 2004 from the...

Search for: within All of dW

Use + - ( ) " " Search help

IBM home | Products & services | Support & downloads | My account developerWorks > Rational

RUP iteration planningAnthony Crain IBM 12 Jul 2004

from The Rational Edge: This article traces the steps required to plan sequential software project iterations while following the IBM Rational Unified Process. The author illustrates RUP templates and associated workflows in order to produce a plan relevant to the essential RUP disciplines.

When planning an iteration using IBM Rational Unified Process,® or RUP,® people often get confused about how to start. Although templates in RUP itself and MS Project tools can help auto-generate a RUP style plan, creating a plan manually can really help you understand and manage your RUP iteration.

In this article I will show how simple it is to create an accurate iteration plan using the basic RUP toolset.

Input artifacts To create your iteration plan you really only need two basic inputs. First, you need to know what RUP phase the planned iteration belongs to, and second, you need a well-written RUP development case. Knowing the phase will allow you to create the right kind of plan. Having the development case will tell you exactly what the plan should contain.

Development case redefined Creating a plan from a development case is actually fairly easy, as you will see, once we understand what this artifact is all about. I have been told by RUP enthusiasts that the development case artifact is not useful. This is wildly untrue. In fact, I will show you how it can single-handedly drive your project management planning.

I will note that, as with almost every RUP template I’ve ever used, the development case artifact could be improved. However, don’t misinterpret that statement. RUP templates are far better than anything I could create from scratch. But given their elevated starting point, along with my ability to architect information for maximum communication, I see room for improvement. Naturally, each of us brings great experience to the table that we can use to improve a basic set of artifacts. And if we don’t keep reusing and improving each others' basic artifacts — i.e., starting points — we will always be starting from scratch and will only get so far in our effort. By launching ourselves from someone else’s starting point we can fly high indeed and start to create world class artifacts.

Therefore, to create a fully optimized development case artifact, I started with the RUP template. You will notice that RUP is heavily artifact-focused, yet there is little guidance on how to use those artifacts differently in each phase. The definition in RUP for the development case states: “The development case describes the development process that you have chosen to follow in your project.”

So the artifact focus of the development case template doesn’t completely reflect its definition. In my current best practice development case template, I recommend focusing on what workflow details you plan to execute, then focus on the artifacts within the context of each workflow detail. If you are not sure what a workflow detail is, click on any RUP discipline, and the activity diagram will show the workflow details. For example, there are only six workflow details in the Requirements discipline.

Contents:Input artifactsCreating the iteration planSummaryNotes

About the authorRate this article

Subscriptions:dW newsletters

dW Subscription (CDs and downloads)

of 13RUP iteration planning

7/15/2004

© Copyright IBM Corporation 2004. http://www-106.ibm.com/developerworks/rational/library/5335.html

The Rational Edge--June 2004

Figure 1: The RUP Requirements workflow

Note that the RUP discipline workflow diagrams (which are actually stereotyped UML activity diagrams) cover one iteration from the point of view of this discipline. The start state at the top is the start of the iteration, and the end state is the end of the iteration. Some misinterpret this as the start and end of the project, a throwback from waterfall thinking; or they mistake this as the start and end of the discipline, assuming that each discipline occurs in chronological order. In other words, some assume that the end state depicted here precedes the start state of the Analysis and Design workflow, but that isn’t necessarily true.

By acknowledging that this is the start and end of the iteration, and not the project, we can encourage more parallel work, and study the dependencies between tasks. Therefore, these activity diagrams drive iterative project planning.

Writing the development case As I mentioned, to create your iteration plan, you will need a development case. Therefore, it is important that you ensure it gets completed quickly and correctly. It shouldn’t take but a few hours for a new team to assemble a first draft for the current iteration.

To write the development case, assign the nine disciplines (or the subset of disciplines you are using on your project if not all nine) to the most appropriate team members. Their job is to look at the workflow details and decide which ones they will actually need to execute, and which ones they won’t. At first it feels like you have to know a lot about RUP to make that judgment, but that isn’t necessarily the case. Knowing the definitions of the four RUP phases may be all you really need. Let’s look at an example.


7/15/2004

Figure 2: The RUP Requirements workflow

Tasks on plan Given that the Inception phase involves creating a first-cut usage model of the solution and establishing the measurable value of the solution idea but not gathering the detailed requirements, the question becomes: Which of the workflow details shown in Figure 2 (which is identical to Figure 1) will you need? Let’s consider what each of these workflow details requires.

Analyze the problem is about agreeing on the problem and creating the measures that will prove its value to the organization.

Understand stakeholder needs is about sharing the problem and value with key stakeholders and finding out what their needs are surrounding the solution idea.

Define the system is about creating features from needs and outlining use cases, activities which show nicely the high-level requirements and the overall usage model of the system.

Manage the scope of the system is about modifying the scope of what you will deliver based on results so far and selecting the order in which to attack the use-case flows.

Refine the system definition is about detailing use-case flows with the stakeholders in order to create a detailed Software Requirement Specification (SRS) that can serve as the contract between your team and your client and that can drive design and test activities.

Manage changing requirements is about how to handle incoming requirement changes once the project has begun.


7/15/2004

Based on these descriptions and the description of Inception, I would probably expect analyze the problem, understand stakeholder needs, define the system, and manage the scope of the system to be planned for the first inception iteration, but not the other two workflow details. If Inception had more than one iteration I might see manage changing requirements kicking in, but still not refine the system definition. Your decisions might be different and it might also differ for each project under your care.

It is not the project manager’s job to decide which workflow details to perform in each iteration; it is the team’s decision. Basically, the job of the project manager comes down to three tasks, and everything else folds up into them: 1. Plan/Re-Plan 2. Track to Plan 3. Manage Risks to the Plan. That’s pretty much it. I consider status activities part of tracking-to-plan. And I’m open to disagreement on this simplification.

After the team decides what to do via a development case, the project manager should create the plan from the development case they create. Let’s consider one more example of how to tailor the generic RUP workflow based on the current RUP phase, this time using the Analysis and Design workflow in RUP.

Figure 3: The RUP Analysis and Design workflow

Picking which workflow details to include in the development case for the Inception phase is easy, even without individual descriptions of each workflow detail. The activity diagram (Figure 3) clearly indicates that in the Inception phase the only workflow detail needed is to perform architectural synthesis, which is an ugly term for building an architectural proof of concept.

As shown in Figure 3, this workflow detail is optional; however, my projects rarely skip this step. The workflow detail perform architectural synthesis consists of two major steps: 1) deciding if you need a proof of concept, and then 2) building it if you decide you needed one. Most projects need to analyze their risks to determine if a proof of concept is needed, and there are some great best practices to help you make this decision. Therefore, deciding on the need for a proof of concept is not a step that is usually skipped, and I don’t see perform architectural synthesis as more optional than the other five workflow details in Figure 3 for most projects. The optional guard is likely tied to the fact that most projects do NOT need an Inception proof of concept, so the building portion of perform architectural synthesis is optional and frequently skipped in the Inception phase.

In the Elaboration phase, teams build an incremental release (internal or external) that proves the chosen solution architecture can


7/15/2004

support the requirements of the solution. This requires taking the highest-risk requirements all the way through code to test and possibly internal or external deployment. Given this, we will probably need all five of the other workflow details in the Elaboration phase.

During the Construction phase, we build the rest of the flows that we didn’t build as part of elaboration, and we are no longer worried about architecture, focused instead on delivering the highest value solution possible. Based on this, we probably would only need analyze behavior, design components, and design the database.

During the Transition phase, when we are supporting the solution once it has been fully deployed, we would use the same activities as in Construction; but the focus would be more on change requests than use cases.

You can repeat this exercise for the workflow details of the Requirements discipline shown above and for all of the other seven disciplines of RUP. The best part is that you don’t need to do this for all four phases at once! Remember that writing the development case — and planning based on it — is iterative, so you can focus on this iteration only and, therefore, only on the current phase. If the next iteration on the plan will belong to the next RUP phase, then you can proceed to detail your next phase in your development case. This is easier, quicker, and more accurate than waterfall planning for an entire project at once.

Children tasks If you do the above for each workflow it shouldn’t take too long to create a development case for a single phase. But we do need to add a few children tasks. Many managers try to add the activities within each workflow detail, but in general this will cause problems.

First, this will result in significant delays to creating your plan, as there are an awful lot of activities within the workflow details. You will likely spend more time planning some of these tasks than implementing them. You can create a very manageable plan without that added level of detail. Second, many of the activities repeat in different workflow details. Just check out the first four workflow details in the requirements discipline, and you will see the develop vision activity appear every time, with no indication of what is different in each RUP phase. So I recommend that you avoid using the RUP activities on your project plan.

On the other hand, we do need to understand what resources are being applied to what tasks. So instead of making each activity a child task to the workflow detail in our development case, we should create one child task per role involved in the workflow detail that we plan to use. Let’s look at some examples.

Figure 4: Details for the Perform Architectural Synthesis workflow detail


7/15/2004

Notice in Figure 4, in the yellow rectangle, that there is only one resource with three activities. In this case we do not need to add any children tasks to the plan, as the single role will handle all activities.

Figure 5: Details for the Define a Candidate Architecture workflow detail

In the workflow detail shown in Figure 5, we have two participants: the software architect and the designer. So we will create two child tasks for this workflow detail. We need to invent names to represent each subtask on the plan. If the activity does not repeat, we can use its name directly. Architectural analysis does repeat, but only in perform architectural synthesis; so we can call this child task architectural analysis here, because we haven’t already used that name.

Use-case analysis, on the other hand, occurs in so many workflow details that we avoid using that name. We chose use key abstractions instead. That is, we know from experience that using key abstractions is one of the major concepts of this step. Until you gain similar experience you will have to make your best guess.

Another way to look at this is that we are creating children tasks per yellow area, not per activity. We then abstract a new name based on the whole yellow area’s purpose. We can use the activity name if it occurs uniquely within RUP. In my opinion, RUP authors should not reuse activity names, but this approach allows me to manage that for myself.

Knock-off tasks The last step after finding the children tasks is to list key "knock-off tasks" in the development case and to include key input or output artifacts as well. A list of knock-off tasks is like a to-do list of small objectives. (If you don’t like the term knock-off task, you can use a different one, but it should indicate that the list includes fairly granular to-do items.)


7/15/2004

Identifying the knock-off tasks is an area in which a consultant or someone with significant RUP experience can dramatically reduce the time to value. We are NOT trying to duplicate RUP here. We are simplifying RUP considerably in this step. You will still need to use RUP for additional details.

Here are a couple of examples. For Analysis and Design, the knock-off tasks for each workflow detail might look like the list in Table 1, which I’ve taken from the standard development case I give to my clients.

Table 1: A simple development case


7/15/2004


7/15/2004

This standard example is fairly simple. It does not describe the input and output artifacts, but this amount of detail is extremely valuable to the team. And although this development case is fairly simplistic, it fits on a single page, which also can be an advantage to a new team.1

Table 2 shows more complex entry for a single workflow detail in the project management discipline. This is taken from another development case template that I share with my clients (note that the business context in Table 2 is different from that in Table 1).

Table 2: A more complex entry for a single workflow detail

In the example shown in Table 2, far more detail has been provided. This level of detail evolved over time. Trying to get to this level of detail on every workflow detail at once would take more time than our projects have to spare.

Remember, while it is the job of the project manager to ensure a development case is written to guide their planning, the team that will be following the plan should create the development case together. This is how the team influences what gets placed on the plan.

Creating the iteration plan At this point you should have the development case in place. You have probably figured out that creating the work breakdown structure won’t be hard once the development case is written.

But there are still a few final tips and thoughts I’d like to share. Using a planning tool, such as Microsoft Project, you will find it simple to place each workflow detail onto the plan. On previous projects I have tried two different approaches for organizing the work breakdown structure (using Gantt charts like the one in Figure 6 below). I’ve tried to organize the tasks on the plan in chronological order, and I’ve tried organizing the tasks by discipline. These two approaches have different advantages and drawbacks.

Let’s take a look at an actual project in which our current best practices for laying out the tasks in the work breakdown structure were determined in RUP.

Grouping tasks: A lesson in confusion In chronological order, the plan might appear as depicted in Figure 6. Based on an actual project on which I was a consultant, each task was color coded to match (as closely as possible using MS Project’s color palette) the colors of the RUP disciplines.

Conceive New Project

Knock-off tasks Purpose Role Average time

Established environment

New environment

Write business case Write Risk List Share with PRA and gain funding for Inception phase

Purpose is to justify funding by putting together a quick document to show the idea for the project. In the future, new team members can read this to see how the project has been positioned to the PRA, and to get a high-level introduction to the system. The business case will be updated at each iteration. The risk list will be updated often.

Project manager

1 day 1 day

Input Artifacts: None Output Artifacts: business case, risk list, review record funding inception Tools: IBM Rational ClearQuest for risk list, Word for business case, e-mail with acceptance for review record


7/15/2004

Figure 6: Iteration plan organized chronologically

While you can’t easily read the details of this plan, you can tell by the colors, and by the position of the Gantt chart bars, that this plan was not organized by discipline but rather by time. Each task precedes or starts with the next one. For example, the first two tasks are in the project manager discipline, and so are the last two. Clearly, the PM discipline tasks were not grouped.

Using a sequential order gave project managers a clearer understanding of what came next in this project, but it became difficult to reconcile this sequence with the development case because the development case was grouped according to discipline — in other words, all the project manager tasks were together, all of the requirement tasks were together, and so forth. The table of contents based on that development case is shown in Table 3 below.

Table 3: A development case organized by discipline


7/15/2004

So the plan was in sequential order, but the development case was in discipline order, and the project managers had a harder time trying to reconcile the two. To fix this problem, the project managers attempted to modify the template so that the workflow details were in sequential order to better match the iteration plan. The table of contents then looked more like Table 4.

Table 4: Development case reorganized by sequence


7/15/2004

This worked well for planning because the project managers could, for the most part, cut and paste the table of contents into their project plan. But now it became harder for the rest of the team to find the tasks they owned, since they were no longer logically grouped, so ultimately this was deemed a poor choice. We saved the template, of course, to remind ourselves of the attempt. By the way, the current recommendation for iteration plans in RUP is to organize both the plan and the development case by discipline.

Writing queries to identify critical tasks During that project, we also created a few Microsoft Project queries to help the project managers look for a clear, single view of interdependent tasks. This is because the plans could span pages vertically, and a task listed low on a given page might be slated for the first week with many entries for subsequent weeks above it.

The queries are easy to write: List all tasks starting this week (or whatever dates you choose), list all tasks ending this week, and list all tasks ongoing this week. The project manager would then run these three queries and print out the results, then proactively wander around to the team asking “Are you going to start this on time? Are you going to complete this on time? How are these items going? How can I help?”

Using the RUP work order In addition to the workflow details, I recommend that you put in the role-specific children tasks as well, and assign them the appropriate resources. But DON’T put in the knock-off tasks, or your plan will be too granular to manage well. It will take too long to create and will be difficult to modify when changes become necessary.

Instead, use another RUP artifact called the work order, which RUP defines as follows: “The work order is the project manager's means of communicating what is to be done, and when, to the responsible staff. It becomes an internal contract between the Project Manager and those assigned responsibility for completion.”

It goes on to say you can use a whiteboard, and the project plan for tracking, or use IBM Rational ClearQuest to track them automatically. The idea is you jot down the knock-off tasks with the resource responsible for the task separate from the project plan. When the knock-off tasks are done, the work order is complete and we mark it complete in MS Project. There is even an integration between MS Project and ClearQuest that allows you to plan in MS Project, generate work order records, and have the plan update itself when the work orders are marked complete in ClearQuest.

Another technique is to assign all the work orders to the team member, who can jump from one to another if the work orders get blocked, raising any needed risks (also via IBM Rational ClearQuest) in the process. If a team member ever runs out of work orders he can camp out in front of the PM’s office with a sandwich until he gets new ones, or he can switch to another project and get new work orders from different managers.

The point is this: If you plan too deeply, your planning will simply take too long and be difficult to manage and track against. Work orders can give you the granular level of management you need without the overhead.


7/15/2004

Summary A well-written development case should show the project’s process — not just the artifacts. The process is described by outlining which workflow details the project will be targeting. The project team writes the development case. The project manager uses the development case to create a work breakdown structure in his preferred tool and works with the team to assign times and dependencies. The plan should not detail the activity level but should have one subtask per workflow detail if there is more than one role involved. The development case should list detailed knock-off tasks for each task, but these should not be in the iteration plan. Instead, work orders should be used to track the more granular knock-off tasks.

Notes 1 In appearance, this development case differs widely from the standard RUP template in that it doesn’t discuss artifacts at all. See my article on the artifacts of Analysis and Design to understand the three artifacts you will need to use for all six of these steps.

About the author Anthony Crain is a software engineering specialist with the IBM Rational Services Organization. In addition to helping clients roll out the IBM® Rational Unified Process®, or RUP®, he also trains engineers in requirements management with use cases, Object-Oriented Analysis and Design (OOAD), and RUP. He learned OOAD and use-case modeling while at Motorola for five years, then sharpened his skills at Rational. An honors graduate from Northern Arizona University, he holds a B.S. in computer science and engineering.

What do you think of this document?

Comments?

Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

Submit feedback developerWorks > Rational

About IBM | Privacy | Terms of use | Contact


7/15/2004

rup iteration planning - ibm · rup iteration planning anthony crain ibm 12 jul 2004 from the...

Documents