Agile Estimating & Planning

June- 2019
Agile Estimation & Planning
Presented By-Md. Mojammel Haque

CSM, CSPO, CSD, CSP
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
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

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

Effort = Amount of Work + Uncertainty + Risk + Complexity further
*. 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.
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
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”
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

Agile Planning
Plans are nothing; planning is everything.

Dwight D. Eisenhower
Focus more on the planning than on the plan

Mike Cohn
Agile Planning
Scrum Planning Onion Graphical representation of the layers of planning t hat are built into Scrum
Agile Planning
Release
 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
 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)
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
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
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 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
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.
Thanks For your Patience
Md. Mojammel Haque

CSM, CSPO, CSD, CSP
Software Architect, Raven Systems Ltd.
Mobile: 01817045882
Email: [email protected], [email protected]
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

Agile Estimating & Planning

Uploaded by

Copyright:

Available Formats

Agile Estimating & Planning

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Estimating & Planning

Uploaded by

Copyright:

Available Formats

June- 2019

Agile Estimation & Planning

Presented By-Md. Mojammel Haque

Estimation in Agile is a method of measuring

 Estimation allows us to prioritize our features effectively based

 Estimation helps us to make our best plan

 Eiffel Tower is 2.31 Times Larger

 CN Tower is 3.96 Times Larger

 Petronas Towers are 3.24 Times Larger

 Burj Khalifa is 5.93 Times Larger

• Set a number to define the required effort

• Then set same numbers to all others story

• Set double point of baseline who will

• Similarly follow the process for triple and

1. All team member will involve in Planning Poker Game

 At the beginning of the project if the team members have prior

 After first sprint we can measure the velocity of the team by

 After third sprint we will average the story points that

 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

Plans are nothing; planning is everything.

Focus more on the planning than on the plan

Each Team member will answer following three questions

Cart Before the Horse

Adapting New Shiny Technologies

Md. Mojammel Haque

You might also like