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