Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.01 Project Management Review Eclipse Process Framework 30 Jun 2006

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.02 Objectives Review OpenUP/Basic PM elements and EPF examples –Project plan –Iteration plan –Work items list –Risk list –Status assessment Compare/align with Cohns Agile Estimating and Planning –Release plan –Release burndown –Iteration plan –Iteration burndown Discuss recommendations

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.03 Agile Estimating and Planning Recent book by Mike Cohn (Nov 05) Defines roles, activities, work products, techniques, and metrics –Activities not really assigned to roles –Diagrams seem to represent what the team needs to do (from a project planning perspective) Uses planning onion for hierarchy of planning time elements Describes estimation and prioritization (desirability and financial) techniques

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.04 Agile Estimating and Planning Describes two levels of planning –Release and iteration planning Discusses buffering and multiple-team projects Monitor release plan with release burndown charts Describes parking-lot chart for theme coverage Monitor iteration plan with iteration burndown chart –Based on the task board Describes end-of-iteration summary

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.05 Cohns Roles Product owner Customer Developer Project manager

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.06 Planning Onion Day Iteration Release Product Portfolio Strategy

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.07 Cohns Release Plan Describes –Number of iterations –Iteration length –Estimated velocity –Release date Set of user stories for current release –Selected from prioritized list (i.e. user story list) –Estimated with points –Allocated to iterations Total number of points cannot exceed possible number of points in release –Velocity (points/iteration) x iteration

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.08 Cohns Iteration Plan Each story is realized by completing a set of tasks –Expanding story into tasks Task not allocated to team members during planning Describes iteration goals (handful) Task estimation done by team members Describes velocity- and commitment-driven planning

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.09 OpenUP Implications Notion of releases and iterations seems to fit pretty well Relation to Scrum planning and measurement seems well-aligned Pretty much focuses on project management only Themes –Use cases, collections (or packages) of use cases

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.010 OpenUP Implications Point estimation –Use case point technique –Add number of flows (basic + alternate) as overall base complexity –Optionally weight by number of actors User stories must fit within one iteration –Causes existing user stories to be split –Seems like allocating use case flows to iterations –Would need to identify points per flow (to measure development burndown) –Shouldnt require physically disassembling the requirements specification (i.e. use case)

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.011 OpenUP Development Plan Put iteration goals in development 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?

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.012 OpenUP Dev Backlog – Observations Appears that Bugzilla is the development backlog for EPF project 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 development to specific iterations Become assignable tasks related to requirements and change requests –What do we do with tasks that arent 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?

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.013 EPF Observations Do have not formally documented requirements Are using an Excel spreadsheet for release burndown –Should probably by using iterations as the time element, not week (should show up in iteration burndown instead) –Are not estimating size of effort (i.e. points) Do not have a formal iteration plan –Are not estimating effort to complete tasks in ideal days/hours –Are not measuring iteration burndown –Have not identified test cases for iteration –Risks are not being formally managed Need to keep in mind EPF is doing things beyond scope of OpenUP/Basic –EPF is a large process development project (not a software development project) and has a large distributed team (not a small team) and has multiple subprojects (and subteams)

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.014 OpenUP – Development Item

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.015 OpenUP – Iteration

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.016 OpenUP – Task Introduce team member as an enactment metamodel element? Seems like task is an enactment element (an instance of task use which is an instance of task definition)

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.017 OpenUP – Recommendations Role: Development Lead Work Product: Development Plan Work Product: Iteration Plan Work Product: Task List Work Product: Development Backlog –Or Work Product: Release Plan? –Or no work product? Just put in development plan? Work Product: Risk List Work Product: Status Assessment Report: Development Burndown Report: Iteration Burndown