closed loop - software estimation to delivery

27
Closed Loop: Project Estimation to Delivery Ahsan Saleem Engagement Manager

Upload: ahsan-saleem

Post on 27-Jun-2015

250 views

Category:

Technology


2 download

DESCRIPTION

A check and balance approach to Software estimation to delivery using Scrum method via JIRA

TRANSCRIPT

Page 1: Closed loop - Software Estimation to Delivery

Closed Loop: Project

Estimation to Delivery

Ahsan SaleemEngagement Manager

Page 2: Closed loop - Software Estimation to Delivery

Closed Loop?

Closed loop refers to a check and balance approach to project delivery

As a services company we should measure certain metrics that guide project managers where and why projects go over (or under) estimated budget

Page 3: Closed loop - Software Estimation to Delivery

Presentation Agenda

1. Process

2. Metrics

3. Slippage Analysis

4. ‘Catch 22s’

Page 4: Closed loop - Software Estimation to Delivery

Process

1. Creating WBS

2. Estimating WBS

3. Creating project plan

4. Project kick-off

5. Executing sprints and gathering metrics

6. Analysis

Page 5: Closed loop - Software Estimation to Delivery

Creating WBSProcess – Step 1

Page 6: Closed loop - Software Estimation to Delivery

WBS Content

Think of project in modules/features, user stories and tasks

WBS is not just development

Testing, scripts, builds, product definition, UI work etc. are all part of WBS

Our estimation sheet automatically ads PM, testing, and bug fixing effort

Generally in mobile and web apps we can derive WBS screen by screen plus backend processes

Page 7: Closed loop - Software Estimation to Delivery

Sample WBS

Page 8: Closed loop - Software Estimation to Delivery

WBS Rules

WBS items should not base on un-documented assumptions

WBS item should define functionality and not a mere UI item• E.g. Login button IS NOT a WBS item

• Login feature (including UI) IS a WBS item

Ask maximum questions to client/sales team, lesser the assumptions better the WBS

Break bigger items that go over 2 days into smaller items

Too small an items are seldom useful e.g. 2 Hour tasks

Page 9: Closed loop - Software Estimation to Delivery

Estimating WBS

Process – Step 2

Page 10: Closed loop - Software Estimation to Delivery

Estimation Process

PM should create the WBS

Senior engineers should provide effort estimate

How to assign days/hours to a task?• Based on previous experience

• Avoid re-inventing the wheel and consider existing modules

• A very aggressive estimate is equally harmful as a very safe estimate

• Delivery team will be separate from estimate team so realistic estimates will help

Make detailed notes in assumptions column as it will greatly help the implementation team• Suggested modules

• Assumptions

• Suggested approaches

Ideally WBS items should directly translate into tickets

Page 11: Closed loop - Software Estimation to Delivery

Creating Project Plan

Process – Step 3

Page 12: Closed loop - Software Estimation to Delivery

Project Plan

A project plan will help layout overall picture of project start till delivery

Sprints can be derived from the project plan

Deviating from project plan is not a bad thing but you will be able to track it

MS Project Plan and OpenProj both decent tools for project plan creation

Page 13: Closed loop - Software Estimation to Delivery

Sample Project Plan

Page 14: Closed loop - Software Estimation to Delivery

Project Kick-OffProcess – Step 4

Page 15: Closed loop - Software Estimation to Delivery

Project Kick-Off Meeting

Introduce project team (internal and external i.e. client)

Discuss project requirements and WBS and identify gaps

Discuss with Sales/Engagement manager for gpas

Discuss deliverables

Discuss milestones and dates

Page 16: Closed loop - Software Estimation to Delivery

Executing Sprints and Gathering

MetricsProcess – Step 5

Page 17: Closed loop - Software Estimation to Delivery

Ticket Creation

WBS items should translate into tickets

WBS estimate should go into ‘Original Estimate’, even if you do not agree to its number value

Engineer should log actual hours worked on ticket and DO NOT manually change remaining estimate

PM should label on ticket in case the delta between original estimate and logged hours is more than 25%

Page 18: Closed loop - Software Estimation to Delivery

Use Time Tracking report to spot slipping issues

Page 19: Closed loop - Software Estimation to Delivery

Use labels to mark tickets that need analysis

Original estimate too tight/loose

• Who to judge: PM or a senior engineer

• Apply label Original-Estimate-Issue

Unclear or missed requirements from sales/estimation collateral

• Should apply label Missed-Unclear-Req

Scope change

• PM makes this call and applies a label on ticket; Scope-Change

You can search based on labels

Page 20: Closed loop - Software Estimation to Delivery

Utilize Sprint Retrospective Meeting

Retrospective meeting is a good time to touch base on tickets which went over and under initial estimate

PM should label/comment on tickets with implementation engineer’s consent

All major deltas should be communicated to Engagement Manager

Page 21: Closed loop - Software Estimation to Delivery

Slippage Analysis

Page 22: Closed loop - Software Estimation to Delivery

Using Interactive JIRA Graphs

Report can be generated for a Sprint or total project

Page 23: Closed loop - Software Estimation to Delivery

Issue Details

The query can be altered live for more analysis

Page 24: Closed loop - Software Estimation to Delivery

Report based on Assignee

Page 25: Closed loop - Software Estimation to Delivery

Report based on Component

Page 26: Closed loop - Software Estimation to Delivery

Catch 22’s

Page 27: Closed loop - Software Estimation to Delivery

Catch 22’s

The purpose of ‘Closed Loop’ is not a blame game, rather improve process and knowledge for overall company

The exercise should not be presented as a police activity so it does not discourage team members

The process will not work if engineer’s do not log hours or not put Original Estimates