copyright © 1998-2006, armstrong process group, inc., and others all rights reserved made available...

Made available under EPL v1.0 1

Copyright © 1998-2006, Armstrong Process Group, Inc., and others All rights reservedCopyright © 1998-2006, Armstrong Process Group, Inc., and others All rights reserved

Project Management Review

Eclipse Process Framework19 Jun 2006


Copyright © 1998-2006, Armstrong Process Group, Inc., and others All rights reserved

Objectives• Review OpenUP/Basic PM elements and EPF examples

– Project plan– Iteration plan– Work items list– Risk list– Status assessment

• Compare/align with Scrum– Release burndown– Product backlog– Sprint backlog– Sprint burndown

• Discussing piloting (i.e. “testing”) OpenUP/Basic content



OpenUP Project Plan – Definition

• Brief description– This artifact gathers all information required to

manage the project. Its main part consists of a coarse-grained plan, containing project phases and milestones.

• Purpose– The purpose of the Project Plan is to provide a central

document where the any project team member can find the information on how the project will be managed.



OpenUP Project Plan – Implied Content

• Project constraints• Scope and duration• Measurements• Phases and milestones• Number, length, and objectives of iterations• Staffing• Development process

Implied content based on steps of Task: Plan the Project



OpenUP Project Plan – Observations

• Implied content does not match current template– Updating template already in Bugzilla

• Really do not have an OpenUP Project Plan for EPF project– Development plan is close– Doesn’t appear to have been maintained

• Didn’t we add another iteration?• Iteration goals don’t quite line up any more; some should be

removed (i.e. agile stuff)



OpenUP Project Plan – Observations

• Put iteration “goals” in project plan– Similar to what is in current development plan for

each milestone– Put iteration “objectives” in iteration plans– Based on premise that goals are more abstract and

coarse-grained than objectives

• Should OpenUP have a “release planning” element?– Should we rename the step in Task: Plan the Project

“Plan project scope and duration” to “Plan releases”?



OpenUP Iteration Plan – Definition

• Brief description– This artifact is a fine-grained plan describing the

objectives of a given iteration and how they will be evaluated. It contains a list of work assignments for the particular iteration.

• Purpose– Facilitating the communication of the goals,

objectives, tasks and assignment for a given iteration.



OpenUP Iteration Plan – Implied Content

• Objectives (“high-level tasks” or “goals”)– Related to risks, timebox, requirements

• Iteration tasks (“smaller tasks”)• Allocated work items• Elements to test

Implied content based on steps of Task: Initiate Iteration and Task: Plan Iteration



OpenUP Iteration Plan – Observations

• Implied content does not match current template– Mixes “objective” and “task” as same thing– Updating template already in Bugzilla

• How to the “items” in the iteration plan relate to EPF metamodel elements?– Are they activities, tasks, steps, descriptors, etc???

• There appear to not be any iteration plans for EPF project



OpenUP Work Items List – Definition

• Brief description– This artifact contains all work that has to be done in

project.

• Purpose– To collect all work that has to be done in a project,

so work can be prioritized and effort estimated.



OpenUP Work Items List – Implied Content• Name• Type• Priority• Estimate• Release

Implied content based on Artifact: Work Items List



OpenUP Work Items List – Observations• Appears that this is a collection of requirements

and change requests and tasks– However, it is not the requirements or the change

requests– It is a convenient place to prioritize them

• Used to assign work to individual team members for specific iterations

• Perhaps work items are assignable tasks related to requirements and change requests– What do we do with tasks that aren’t related to

requirements or change request (such as process-related tasks like project planning and establishing a development environment)?

– Should we just call this the “task list”?



OpenUP Work Items List – Observations• Appears that Bugzilla is the work item list for EPF project• However, some “items” need to be broken down into

more fine-grained “item”– For example, “#146662: All disciplines: no discipline text” might

need to be broken into smaller items, one for each discipline– Perhaps “All disciplines will have explanatory text” is the detailed

“requirement” and the items for each discipline are the “work items”

• There are no detailed requirements for EPF project documented anywhere– There are change requests (and a lot of them for “missing”

requirements)



Scrum Product Backlog – Definition • The Product Backlog is the master list of all functionality

desired in the product• Product Owner prioritizes the items in the Product

Backlog • Team determines which items they can complete during

the coming Sprint• The team then moves items from the Product Backlog to

the Sprint Backlog• In doing they expand each Product Backlog item into

one or more Sprint Backlog tasks so they can more effectively share work during the Sprint

• A very interesting prospect is expressing Scrum backlog items in the form of Extreme Programming's User Stories.

From Mike Cohn @ Mountain Goat Software



Scrum Product Backlog – Content

• Priority• Item #• Description• Estimate• Assigned To



Scrum Product Backlog – Observations• As it is defined as a list of all product capabilities, it

seems as these are the product requirements– OpenUP Features, Use-Case Model, and Supporting

Requirements (and/or perhaps scenarios) are same as Scrum Product Backlog

• Items on product backlog are decomposed into smaller tasks on sprint backlog– Implies product backlog items and sprint backlog items are not

the same thing, but related– In certain situation a single product backlog item may become a

single sprint backlog items, but this may be the exception, not the rule

– Supports idea than an OpenUP work item is one or many tasks related to implementing a requirement or change request



Scrum Sprint Planning and Assessment• Collectively the Scrum Team and the Product Owner

define a "Sprint Goal," which is a short description of what the sprint will attempt to achieve– The success of the sprint will later be assessed during the Sprint

Review Meeting against the Sprint Goal, rather than against each specific item selected from the Product Backlog

• During the Sprint Review Meeting the project is assessed against the Sprint Goal determined during the Sprint Planning Meeting– Ideally the team has completed each task planned for the sprint

but it is more important that they achieve the overall goal of the sprint

• Implies a distinction between iteration goals/objectives and tasks



Scrum Sprint Backlog – Definition

• The Sprint Backlog is the list of tasks that the Scrum Team is committing that they will complete in the current Sprint

• Items on the Sprint Backlog are drawn from the Product Backlog by the team based on the priorities set by the Product Owner and the team's perception of the time it will take to complete the various features



Scrum Sprint Backlog – Content

• Assigned To• Description• Estimated effort per week



Scrum Sprint Backlog – Observations

• Appears to not be prioritized– Only the Product Backlog is prioritized– Sprint tasks inherent the priority from their related

backlog items?



Scrum Burndown

• Burndown is a trend report showing the amount of work remaining for a period of time

• Release burndown– Shows amount of work remaining based on “points” –

measure of requirements coverage based on scope and complexity

• Sprint burndown– Shows amount of work remaining based on time

estimates of allocated tasks



Relationships

Feature

Use Case SupportingRequirement

Related to Composed of Traceability

Work Item List

Work Item /Assigned Task

Change Request

Requirement

IterationTest Case

{xor}

0..1

0..1

comprised of

0..*

Team Member

0..*

0..*

1

1

Objective Risk

0..*

Product Backlog comprised of

0..*Process

Task

0..*

{xor}

0..1



Overall Observations• Requirements are the product backlog

– For OpenUP most of the “functional” detailed requirements are the process elements

• Work items are the tasks for an iteration (sprint backlog)– Based on requirements, change requests, and

process tasks

• Still need a separate iteration plan for objectives, risks, and test cases

• Project plan contains iteration goals, but not detailed iteration objectives

• Consider adding releases to project plan



Piloting OpenUP/Basic Content

• Should pilot subset of OpenUP/Basic on EPF project– Project management– Requirements– Testing

• Identify external, commercial pilot opportunities

copyright © 1998-2006, armstrong process group, inc., and others all rights reserved made available...

Documents

plan iteration slide

project plan project

project plan similar

epf project development

epf project slide

armstrong process group

epl v1

iteration objectives