1. Agile Estimation
V. Lee Henson CST

2. Founded in 2007 - Salt Lake City, UT
Personally Trained, Coached, and or Mentored at 41 of the Fortune 100 Companies
Deep understanding of Agile & Traditional Project Management, (PMP), RUP, Lean, Kanban, Scrum, (CST), XP, & PMI-ACP
Proven Applied Agile Principles in Software, Hardware, Financial, Insurance, Construction, Medical, Marketing, Legal, Entertainment, Research, Military, Government, Retail, Education, Law Enforcement, and many more...
Website:

3. V. Lee Henson CST Certified Scrum Trainer
Project Management Professional
PMI- Agile Certified Practitioner
Certified Lean Agile Professional
Motivational Speaker & Executive Coach
Author of The Definitive Agile Checklist
Inventor of Rapid Release Planning
Information Technology / Psychology

4. Objectives: What am I going to get? When am I going to get it?
How much is it going to cost?
The What If’s? are quite an interesting bunch. I remember the day when my children first stated asking this very question.
Can I ride my bike to the park? …No, not now
What if I invite a friend to come along? No = What she really hears = You do not trust my friends?
What if I ride slow? No = What she really hears = You feel I am not safety conscious?
What if I walk instead of ride? No = What she really hears = You do not even trust me to walk across the street?
What if I just don’t go? What she really hears = You do NOT trust me at all?
Agile teams feel very much the same way when we do certain things in the workplace.
Why did this project fail? Why did we deliver late? Why did we exceed our budget?
The plan to execute did not match the strategic vision of what the customer wanted = The Executive vision was not accurate and / or not communicated well.
The Management team failed to provide me with the tools / resources I needed to do the job to the best of my ability. = It’s a managers fault.
The requirements were not clearly defined or, we did not have a clear interpretation of what was to be done. = It’s the Product Owner
We had too many outside interferences and were constantly putting out fires. = It is the Project Manager or ScrumMaster
We simply failed to get it done. We the team take full responsibility.

5. Agile vs. Plan Driven

6. Executive Project Dashboard
Will Be Done
At Risk
Will Not Be Done
Backlog Item #1
Backlog Item #11
Backlog Item #21
Backlog Item #2
Backlog Item #12
Backlog Item #22
Backlog Item #3
Backlog Item #13
Backlog Item #23
Backlog Item #4
Backlog Item #14
Backlog Item #24
Backlog Item #5
Backlog Item #15
Backlog Item #25
Backlog Item #6
Backlog Item #16
Backlog Item #26
Backlog Item #7
Backlog Item #17
Backlog Item #27
Backlog Item #8
Backlog Item #18
Backlog Item #28
Backlog Item #9
Backlog Item #19
Backlog Item #29
Backlog Item #10
Backlog Item #20
Backlog Item #30
60 % WBD
40 % AT risk

7. Scrum vs. Waterfall

8. The 3 C’s of a Good User Story:
1) The Card - The topic of the backlog item, the high level description of the desired system behavior.
2) The Conversation - Detailed requirements are only discovered after the backlog item has been pulled into a sprint. This is a dialog between the product owner and the development team.
3) The Confirmation - Criteria that insures the backlog item was completed to the specifications of the product owner. The customer will evaluate the competed backlog item against the acceptance criteria, and if all tests pass, approve the backlog item by the end of the sprint.

9. The Index Card - Overview:
Title - The title should be 10 words or less.
Description- As a ________
I would like to ______________________________
so that ______________________________.
Business Priority
H-M-L
T-Shirt Size
XS - S- M
- L - XL
MoSCoW
M-S-C-W

10. Writing a Good User Story Description Template:
As a _________________________ I would like to __________________ so that ________________________________.
Example: As a (role or persona), I would like to (execute an activity), so that I can (see or achieve a value or benefit).

11. Product Backlog Design:
All possible system features are captured in a stack rank ordered list called the product backlog.
New features can be added to the backlog at any time.
Features in the backlog have a gross estimate of effort and or value.
Each Sprint implements
The highest priority features
High
Low
Features
Each new feature is
Prioritized & added to the stack
Features may be reprioritized
At any time
Features may be removed

12. Breaking Down The Work:
Let the finger pointing begin! This is the place where the rubber hits the road. It is especially easy for people to quickly assess the situation and identify anyone else who was the cause of the debacle. This is the greatest point of contention amongst teams. This is also the greatest opportunity for the team to retrospect and adjust in order to prevent this from happening in the future.
The key here is to stop pointing fingers and start searching for clues…

13. What About Business Priority?
We all know the business has a 3 point ranking scale for priority of backlog items: High, Really High, or Really Really High.
The business needs to use tools to help them understand that not everything can be of the highest priority.
With the understanding that we would not be doing the work if it were not important, which items have the greatest urgency? Can we arrange them into High, Medium, and Low categories?
Two websites to assist with priority:

14. Time vs. Relative Complexity:
Let’s paint the room!
How many hours will it take?
Why all of the different answers?
Have any of you painted before?
Compared to something else you have painted, would it be easier to determine how difficult it would be to paint the room?
Is it easier to reach consensus?

15. Planning Poker - Does It Work?

16. Let’s Use a T-Shirt Size...
Smaller Than XS = a Task.
Extra Small = 1
Small = 2
Medium = 3
Large = 5
Extra Large = 8
Larger than XL = an Epic

17. Understanding MoSCoW:
MoSCoW = more than a Russian Capital
Must Have
Should Have
Could Have
Would Like
Every iteration should have a mix of the above types of items.
Stake holders LOVE the Would Likes.
The Product Owner drives the product backlog and creates the rank order based heavily on the MoSCoW ratings.

18. Understanding Velocity:
The rate at which a team can produce working software
Measured in non-time-referent terms (e.g., Story Points) per Sprint
More accurately stated, it is measured in terms of the stabilized number of Story Points a team can deliver per sprint of a given length, and with a given definition of Done.
Used for estimation and planning
Can be artificially increased by cutting corners on quality
Must have stabilized to be reliable
Should not be used as a measure of comparison across teams
Lean concept of Limiting Work to Capacity
Unfortunately, the first group looking to hold someone responsible for project failure is the executive team. Are you prepared to give a complete report on why the team failed to deliver? Have you considered doing a demo of what has been completed? What reaction might you expect from the executive team? What could we do to alleviate the pain in the future?
What if we had the ability to promise both on-time delivery and precision metrics?
What if we could help the Executive understand their role in the Agile process?
What if we had the Power to help frame the Vision?

19. Velocity - An Example:
Example: Team A is working in 2-week sprints on work that it has estimated together. Team A has been working together for several sprints, and consistently delivers between 18 and 23 points of working software every sprint.
We could reasonably expect Team A to deliver roughly 20 points per 2-week sprint, and so we consider that to be the team’s velocity for planning purposes.
If there are eight 2-week sprints in a release, we can extrapolate that Team A has the capability to deliver 160 points in a release.
When I say the term Sail Well, what specifics come to mind? Some would consider this great advice, but the question remains is this great counsel for an Agile team? What exactly does sail well mean? Does it provide concrete direction? One could argue that with direction already solidified, this advice could be the first indication of an executive maintaining control of the vision while allowing the team to chart it’s own course.
We all know there is more than one way to reach the final destination. This may be why I selected to use the word Strategy in lieu of vision. Vision indicates a dream or long term goal that has suddenly become within reach. Strategy includes vision and careful planning with the rest of the crew to make certain the ship remains on target. Charting the most desirable and or efficient course becomes the next step in the process.
Consider the difference between basic Vision and having a Strategy in place. Take the time to find the most strategic solution. Now is also a great time to realize that the executive is not at fault. Should the strategy not be clearly outlined, someone should be speaking up! It is the Team’s responsibility to provide the needed visibility to the executive at every level in order to assist them in maintaining the project at their level.
Part of being an empowered team is Learning to Sail Well!

20. Size (complexity) is estimated
Connecting The Dots:
Size (complexity) is estimated
A story is estimated to be 3 story points in relative complexity
Velocity is measured
“Team A can deliver 20 story points in a 3-week sprint”
Duration is derived
- “Based on Team A’s measured velocity of 20 story points per sprint, it will take Team A 3 sprints to deliver 60 story points.”

21. In Other Words...
Backlog Item estimates answer the question “how big?”, rather than “how long?”
Size estimates and observed Velocity, used together, are answer the question “how long?”
The Second round of finger pointing award goes to the Product Owner and Project Manager.
Did the Product Owner do his or her job of breaking down the Product Requirements Document?
Were all of the stories in the backlog clearly defined?
Did the Product Owner share in the Strategy set forth from the vision?
Was the Product Owner a true representative of the customer?
Was the Product Owner available to the team?
Was the Project Manager able to remove impediments in a timely way?
Did the Project Manager work with the team to help them plan for what their capacity would hold?
Did the PMO Organization pay enough attention to this high profile project?
Could anyone have assisted the team in their quest to do better?
Once again the team needs to see that although these individuals could have contributed to the team’s inability to perform, neither of these individuals should be held accountable.

22. The Five Levels of Agile Planning
Agile teams plan their projects at 5 levels:
Product Vision
T-365
Product Roadmap
T-365 to T-90
Release Planning
T-60 to T-45
Iteration Planning
T-0
Daily Planning
T+1 to T+14

23. Questions?

24. Lee@AgileDad.Com- Twitter @AgileDad - LinkedIn leehenson@gmail.com
Please send me your feedback and or thoughts.
Thank You!
- LinkedIn

25. Questions? Hemant Elhence hemant@synerzip.com 469.322.0349
Hemant Elhence 25 25

26. Synerzip in a Nut-shell
1. Software product development partner for small/mid-sized technology companies
Exclusive focus on small/mid-sized technology companies, typically venture-backed companies in growth phase
By definition, all Synerzip work is the IP of its respective clients
Deep experience in full SDLC – design, dev, QA/testing, deployment
2. Dedicated team of high caliber software professionals for each client
Seamlessly extends client’s local team, offering full transparency
Stable teams with very low turn-over
NOT just “staff augmentation”, but provide full mgmt support
3. Actually reduces risk of development/delivery
Experienced team - uses appropriate level of engineering discipline
Practices Agile development – responsive, yet disciplined
4. Reduces cost – dual-shore team, 50% cost advantage
5. Offers long term flexibility – allows (facilitates) taking offshore team captive – aka “BOT” option 26

27. Our Clients 27

28. Thanks! Call Us for a Free Consultation! Hemant Elhence
Hemant Elhence 28 28 28