Project Management Review Eclipse Process Framework 30 Jun

Project Management Review Eclipse Process Framework 30 Jun 2006 Made available under EPL v 1. 0 1/24/2022 1

Objectives • Review Open. UP/Basic PM elements and EPF examples – – – Project plan Iteration plan Work items list Risk list Status assessment • Compare/align with Cohn’s “Agile Estimating and Planning” – – Release plan Release burndown Iteration plan Iteration burndown • Discuss recommendations Made available under EPL v 1. 0 1/24/2022 2

“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 Made available under EPL v 1. 0 1/24/2022 3

“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 Made available under EPL v 1. 0 1/24/2022 4

Cohn’s Roles • • Product owner Customer Developer Project manager Made available under EPL v 1. 0 1/24/2022 5

“Planning Onion” Strategy Portfolio Product Release Iteration Day Made available under EPL v 1. 0 1/24/2022 6

Cohn’s 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 Made available under EPL v 1. 0 1/24/2022 7

Cohn’s 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 Made available under EPL v 1. 0 1/24/2022 8

Open. UP 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 Made available under EPL v 1. 0 1/24/2022 9

Open. UP 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) – Shouldn’t require physically disassembling the requirements specification (i. e. use case) Made available under EPL v 1. 0 1/24/2022 10

Open. UP 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 Open. UP have a “release planning” element? – Should we rename the step in Task: Plan the Project “Plan project scope and duration” to “Plan releases”? Made available under EPL v 1. 0 1/24/2022 11

Open. UP 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 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”? Made available under EPL v 1. 0 1/24/2022 12

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 Open. UP/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) Made available under EPL v 1. 0 1/24/2022 13

Open. UP – Development Item Made available under EPL v 1. 0 1/24/2022 14

Open. UP – Iteration Made available under EPL v 1. 0 1/24/2022 15

Open. UP – 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) Made available under EPL v 1. 0 1/24/2022 16

Open. UP – 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 Made available under EPL v 1. 0 1/24/2022 17