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

1. Closed Loop:
Project Estimation
to Delivery
Ahsan Saleem
Engagement Manager

2. 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

3. Presentation Agenda
1. Process
2. Metrics
3. Slippage Analysis
4. ‘Catch 22s’

4. Process
1. Creating WBS
2. Estimating WBS
3. Creating project plan
4. Project kick-off
5. Executing sprints and gathering metrics
6. Analysis

5. Creating WBS
Process – Step 1

6. 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

7. Sample WBS

8. 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

9. Estimating WBS
Process – Step 2

10. 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

11. Creating Project Plan
Process – Step 3

12. 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

13. Sample Project Plan

14. Project Kick-Off
Process – Step 4

15. 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

16. Executing Sprints and
Gathering Metrics
Process – Step 5

17. 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%

18. Use Time Tracking report
to spot slipping issues

19. 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

20. 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

21. Slippage Analysis

22. Using Interactive JIRA
Graphs
Report can be generated for a Sprint or total project

23. Issue Details
The query can be altered live for more analysis

24. Report based on Assignee

25. Report based on Component

26. Catch 22’s

27. 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