Agile Estimating and Planning

1. June- 2019
Agile Estimation & Planning
Presented By-Md. Mojammel Haque
CSM, CSPO, CSD, CSP

2. What is Estimation in Agile?
Estimation in Agile is a method of measuring
 How much Efforts will require complete a user story
 How much Time will require to complete a Task

3. Benefits of Estimation
 Estimation allows us to make decision effectively
 Estimation allows us to prioritize our features effectively based
on cost and benefits
 Estimation helps us to make our best plan

4. Problems of Time Based Estimation
Estimation:
Guess for the Amount of time the
development team will require
to complete a task
Target:
Target is the end result of a sprint or a
release of a product.
Commitment:
An agreement to complete certain
amount of work within a particular time
frame

5. Relative Estimation
 Eiffel Tower is 2.31 Times Larger
than Pyramid
 CN Tower is 3.96 Times Larger
than Pyramid
 Petronas Towers are 3.24 Times Larger
than Pyramid
 Burj Khalifa is 5.93 Times Larger
than Pyramid

6. Measure Complexity Relatively
Story Points Amount of Effort require to Complete a Story
• Select a Story from backlog which is easy
to estimate i.e. select baseline story
• Set a number to define the required effort
to complete the story i.e. set baseline
point
• Then set same numbers to all others story
of the Product backlog those will require
similar effort as baseline
• Set double point of baseline who will
require double effort
• Similarly follow the process for triple and
furtherEffort = Amount of Work + Uncertainty + Risk + Complexity
*. Story of Same complexity can require different amount of work e.g.- Saving data from single field and 100 fields will require different amount of times to
design, coding etc.
*. At the beginning of a project stories are not clear so uncertainty takes place
*. Risk of using new technologies, changing of existing unmanaged code etc.
*. Business complexity.

7. Agile Estimation Technique
Planning Poker Technique of Estimating the Required Effort to Complete A User Story
1. All team member will involve in Planning Poker Game
02. Each member will have a set of card with containing numbers
1,2,3,5,8,13,21,40,100 etc.
03. Product owner will select a story from Backlog and describe it’s
details.
04. Development Team will gain crystal clear understating about the
story by asking questions like-
• What should happen in a given scenario?
• What should happen in some negative scenario
• Who will use this? Any particular type of user or all?
05. After discussion Product owner will ask team to assign a number for this story
06. Each member will select a card and put it on the table with face down.
07. Once everyone selected their card the product owner will say Now Show
08. Everyone will turn over their card so that everyone present their can see the estimated number
09. If there any mismatch found then members with highest and lowest numbers will explain the reason of assigning point
10 . Then After explanation follow step 05-09
11. If after 5–6 rounds of playing the game estimation fail meet all members agreement then put it aside for revisit later

8. Velocity Estimation
Velocity No. of Story Points A Team can Complete within A Sprint
 At the beginning of the project if the team members have prior
work experience of similar project then can estimate the
velocity otherwise not.
 After first sprint we can measure the velocity of the team by
calculating how much story points completed by the team in
that sprint e.g.- in first sprint team completed 32 story points
 After third sprint we will average the story points that
completed by the team within past 03 sprints and that will be
the average velocity of the team e.g.- in first sprint team
completed 32 story points, second sprint 35 story points and
third sprint 38 story points. So average velocity = (34+36+38)/3
= 108 /3 = 36. So the average velocity of the team is 36.
• No Incomplete stories /partially completed stories will accountable during calculating the velocity of the team.
• Only consider those user stories who met the definition of “DONE”

9. Definition of DONE
Potentially releasable product that will meet following conditions-
 All design’s of the Story must be completed (Conceptual design, Technical design, User Interface design etc.)
 Required code to complete the user story must be done
 All automated Tests (Unit Tests, Integration Tests etc.) must be completed
 QA tests completed and found no defects
 QA team verified that all acceptance tests has passed
 Successfully code reviewed
 Product manager will test the functionality story and is satisfied
 Code met the quality threshold set by the team
 No security issues has been found
 All documentation has been updated accordingly

10. Agile Planning
Plans are nothing; planning is everything.
Dwight D. Eisenhower
Focus more on the planning than on the plan
Mike Cohn

11. Agile Planning
Scrum Planning Onion Graphical representation of the layers of planning t hat are built into Scrum

12. Agile Planning
Release
Sprint
 A release is a set of features of actual product and therefore visible to real customers.
 A release is the collection of results of multiple Sprints
 Sprint is a feature or set of features within an product release
Example-
 Every two months we have a Release
 Every two weeks we have a Sprint
So, a Release contain 04 Sprints in a Release (02 weeks = 1 Sprint; 1 month = 04 weeks = 2 sprints; so 2 months = 04 sprints)

13. Agile Planning
Release Planning
 Select a set of user stories for release
 Measure required effort to complete each stories i.e. estimate them
 Based on the velocity of the team identify how many sprints will require to complete those stories
 Based on the identified result set the Release
Sprint Planning
 Set a Goal of the Sprint i.e. What can delivered in upcoming Sprint
 Discuss about how to achieve the Goal
 Breakdown each story into several Tasks
 Set required work hour to complete each Task
 Based on the Task Time calculate how many stories can be deliver within this Sprint
 Only Team can how many items to chosen for a Sprint

14. Agile Planning
Daily Planning
Each Team member will answer following three questions
 What he did Yesterday
 What he/she will do today
 Is there any blocks or impediments

15. Agile Planning
Risk Planning
Beyond Release Planning, Sprint Planning & Daily Planning team also need to concentrate to address some
risks that can cost a huge if we ignore them. Some common risks are given below-
Analysis Paralysis
• Team gets stuck in some phase specially in Requirement Engineering phase.
• Run project with incremental releases i.e. Scrum itself is good enough to address this issue
Cart Before the Horse
• Putting too much emphasis on a part of the project that should be done later
• Following MoSCoW *Must Have, Should Have, Could Have, Won’t have (this time)+ method to prioritize
User Stories is good enough to address this issue
Over Engineering
• Adding extra or needless features are added to a product and finally the product become confusing to
its users
• Determine what are clients need and what are clients want and among them eliminate all unnecessary
requirements.
• Follow KISS (Keep it Simple, Stupid) principle during design and develop the software

16. Agile Planning
Micro Management
• Manager wants to involve in every details of a project and interfere in developers work
• Manager need to focus on “Being Agile” instead of “Doing Agile” is the only solution for this issue
Intellectual Violence
• Particular person who
 Asserts his/her opinion on every topic
 Impedes progress by questioning every decision and action
• Project manager will talk him/her personally and suggest any appropriate changes
Adapting New Shiny Technologies
• Team often try to adapt new shiny technologies without knowing about its pros and cons.
• Chances to stuck in middle of the project due to less flexibility of the technology or having lack of
feature to cover what is needed etc.
• Research before committing to a technology. Understand it’s pros and cons and become an expert.

17. Thanks For your Patience
Md. Mojammel Haque
CSM, CSPO, CSD, CSP
Software Architect, Raven Systems Ltd.
Mobile: 01817045882
Email: codermojam@gmail.com, mojamcpds@gmail.com
Facebook: https://www.facebook.com/MojamHaque
Linked-In: https://www.linkedin.com/in/mojamhaque/
GitHub: https://github.com/mojamcpds
Blogs: http://codermojam.com,
https://medium.com/@mojamcpds
Skype: mojamcpds1