Agile Estimating & Planning

  • 1,890 views
Uploaded on

This Deck is set to serve as an introduction to Agile Planning and Estimating! Enjoy!

This Deck is set to serve as an introduction to Agile Planning and Estimating! Enjoy!

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,890
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
162
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • \n
  • \n
  • \n
  • \n
  • The What If’s? are quite an interesting bunch. I remember the day when my children first stated asking this very question. \n\nCan I ride my bike to the park? …No, not now\nWhat if I invite a friend to come along? No = What she really hears = You do not trust my friends?\nWhat if I ride slow? No = What she really hears = You feel I am not safety conscious?\nWhat if I walk instead of ride? No = What she really hears = You do not even trust me to walk across the street?\nWhat if I just don’t go? What she really hears = You do NOT trust me at all? \n\nAgile teams feel very much the same way when we do certain things in the workplace. \n\nWhy did this project fail? Why did we deliver late? Why did we exceed our budget? \nThe 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.\nThe 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.\nThe requirements were not clearly defined or, we did not have a clear interpretation of what was to be done. = It’s the Product Owner\nWe had too many outside interferences and were constantly putting out fires. = It is the Project Manager or ScrumMaster\nWe simply failed to get it done. We the team take full responsibility. \n
  • \n
  • Principles behind the Agile Manifesto\nWe follow these principles: \n\nOur highest priority is to satisfy the customer through early and continuous delivery of valuable software. \nWelcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. \nDeliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. \nBusiness people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. \nThe most efficient and effective method of conveying information to and within a development team is face-to-face conversation. \nWorking software is the primary measure of progress. \nAgile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. \nContinuous attention to technical excellence and good design enhances agility. \nSimplicity--the art of maximizing the amount of work not done--is essential. \nThe best architectures, requirements, and designs emerge from self-organizing teams. \nAt regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. \n
  • \n
  • \n
  • Let’s put this in a different light: \n\nTeam: Will you support us in our efforts to complete this project using Agile Principles? \nBoss: Sure, if that means I get more done in a faster amount of time with fewer resources. \n\nAs the boss walks away he dreams of all of the last minute things he can toss into the fire and get them done quicker than ever before!\n\nThere is still so much left to explore when it comes to what if’s…\n\n \n\n\n\n \n
  • The What If’s? are quite an interesting bunch. I remember the day when my children first stated asking this very question. \n\nCan I ride my bike to the park? …No, not now\nWhat if I invite a friend to come along? No = What she really hears = You do not trust my friends?\nWhat if I ride slow? No = What she really hears = You feel I am not safety conscious?\nWhat if I walk instead of ride? No = What she really hears = You do not even trust me to walk across the street?\nWhat if I just don’t go? What she really hears = You do NOT trust me at all? \n\nAgile teams feel very much the same way when we do certain things in the workplace. \n\nWhy did this project fail? Why did we deliver late? Why did we exceed our budget? \nThe 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.\nThe 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.\nThe requirements were not clearly defined or, we did not have a clear interpretation of what was to be done. = It’s the Product Owner\nWe had too many outside interferences and were constantly putting out fires. = It is the Project Manager or ScrumMaster\nWe simply failed to get it done. We the team take full responsibility. \n
  • Let’s put this in a different light: \n\nTeam: Will you support us in our efforts to complete this project using Agile Principles? \nBoss: Sure, if that means I get more done in a faster amount of time with fewer resources. \n\nAs the boss walks away he dreams of all of the last minute things he can toss into the fire and get them done quicker than ever before!\n\nThere is still so much left to explore when it comes to what if’s…\n\n \n\n\n\n \n
  • Many times we question the what if’s and how they apply to what I do. One of the very earliest projects I had the privilege of working on involved having an active Marine General as the end customer. For those of you without military experience, we are talking about the most impressive form of command and control management ever known to exist. The youngest Marines are educated by their senior officers based on years of experience backing every decision made for them. \n\nOne might go as far as to say that by letting go of the reigns, any complex project would enter a vortex of hopelessness and spin out of control ending in a fiery crash. I am here to state to you all this is simply not the case. In fact, it is almost entirely the opposite approach that works best. Once a team understands what they are being asked to complete and why, they are generally more successful than teams that rely on the command and control structure. My what if conversation went something like this:\n\nWhat if we didn’t jump into this Agile thing feet first? \nWhat if I just kept a running list (backlog), of the things I felt should be worked on first?\nWhat if we met daily for our recap as opposed to meeting once a week for several hours? \nWhat if I could provide you with samples of completed work every 2-4 weeks and let you inspect our progress? \nWhat if I could assure you that by placing confidence in the members of the team that the project stands a higher chance of being completed on time and within scope?\n
  • \n
  • \n
  • \n
  • \n
  • 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. \n\nThe key here is to stop pointing fingers and start searching for clues…\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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? \n\nWhat if we had the ability to promise both on-time delivery and precision metrics?\nWhat if we could help the Executive understand their role in the Agile process?\nWhat if we had the Power to help frame the Vision? \n
  • 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. \n\nWe 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. \n\nConsider 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. \n\nPart of being an empowered team is Learning to Sail Well! \n
  • \n
  • The Second round of finger pointing award goes to the Product Owner and Project Manager. \n\nDid the Product Owner do his or her job of breaking down the Product Requirements Document? \nWere all of the stories in the backlog clearly defined?\nDid the Product Owner share in the Strategy set forth from the vision? \nWas the Product Owner a true representative of the customer? \nWas the Product Owner available to the team? \n\nWas the Project Manager able to remove impediments in a timely way? \nDid the Project Manager work with the team to help them plan for what their capacity would hold? \nDid the PMO Organization pay enough attention to this high profile project? \n\nCould anyone have assisted the team in their quest to do better? \n\nOnce 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. \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Please send me your feedback and or thoughts. \n

Transcript

  • 1. Agile Estimating & PlanningV. Lee Henson CST 1
  • 2. An Introduction To Estimation & Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 2
  • 3. Founded in 2007 - Salt Lake City, UTSpecialize in Public & Private Certification Workshops& CoursesDeep understanding of Agile & Traditional ProjectManagement, (PMP), RUP, Lean, Kanban, Scrum, (CST),XP, & PMI-ACPProven Applied Agile Principles in Software, Hardware,Financial, Insurance, Construction, Medical,Marketing, Legal, Entertainment, Research, Military,Government, Retail, Education, Law Enforcement, andmany more... 3
  • 4. 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 4Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.
  • 5. Objectives:Learn about the Agile Planning& Estimation Mindset (Why?)Learn best practices when itcomes to Agile Planning &Estimating techniques (How?)Do all we can to be openminded & enjoy the session! Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 5
  • 6. Defining Agile: ✤ ag·ile [aj-uhl, -ahyl] - adjective 1. quick and well-coordinated in movement; lithe: an agile leap. 2. active; lively: an agile person. 3.marked by an ability to think quickly; mentally acute or aware: Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 6
  • 7. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals & Interactions over processes & tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is , while there is value in the items on the right, we value the items on the left more. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 7
  • 8. Agile vs. Plan Driven Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 8
  • 9. Scrum vs. Waterfall Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 9
  • 10. Agile Software Development:Agile software development is a conceptual framework for software engineeringthat promotes development iterations throughout the life-cycle of the project.Agile minimizes risk by developing software in short amounts of time. Softwaredeveloped during one unit of time is referred to as a sprint, which may last fromone to four weeks.Each sprint is an entire software project: including planning, requirementsanalysis, design, coding, testing, and documentation. A sprint may not addenough functionality to warrant releasing the product to market but the goal isto have an available release (without bugs) at the end of each iteration.At the end of each sprint, the team re-evaluates project priorities. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 10
  • 11. A Sobering thought... Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 11
  • 12. A Sobering thought... It is possible to finish on schedule and under budget, but still not deliver anything of value. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 11
  • 13. Agile Really Means: Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 12
  • 14. Learning Lean Principles: Higher Quality: “Designed-to-fit” product with flexibility to change. Increased Throughput: Iterative and incremental project and product “chunks” with earlier value delivery. Reduced Waste: Lean, efficient processes with lower costs and higher productivity. “Measure Up”: Fewer, but more meaningful measures Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 13
  • 15. Roles - Who Is ‘The Team’?Most Agile methods profess theuse of 3-5 different roles.Many teams adopting Agilestruggle to determine wheretheir traditional roles fit into anAgile landscapeEvery role fits into 3 Simpleclasses:CustomerFacilitatorImplementor Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 14
  • 16. The 3 C’s of a Good User Story:1) The Card - The topic of the backlog item, the high leveldescription of the desired system behavior.2) The Conversation - Detailed requirements are onlydiscovered after the backlog item has been pulled into a sprint.This is a dialog between the product owner and thedevelopment team.3) The Confirmation - Criteria that insures the backlog itemwas completed to the specifications of the product owner. Thecustomer will evaluate the competed backlog item against theacceptance criteria, and if all tests pass, approve the backlogitem by the end of the sprint. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 15
  • 17. Writing a Good User StoryDescription Template:As a _________________________ I would like to__________________ so that ________________________________.Example: As a (role or persona), I would like to (execute anactivity), so that I can (see or achieve a value or benefit). Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 16
  • 18. Product Backlog Design:High Each Sprint implements All possible system features The highest priority features are captured in a stack rank ordered list called the Each new feature is product backlog. Prioritized & added to the stack Features may be reprioritized New features can be added At any time to the backlog at any time. Features may be removed Features in the backlog have At any time a gross estimate of effort and or value.Low Features Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 17
  • 19. Breaking Down The Work: Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 18
  • 20. The Index Card:Business Priority MoSCoW H-M-L Title - The title should be 10 words or less. M-S-C-W Description- As a ________ I would like to ______________________________ so that ______________________________. XS - S- M - L - XLPO T-Shirt Size Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 19
  • 21. 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 weTwo websites to assist with priority: would not be doing the work if it http://dotmocracy.org were not important, which items http://www.innovationgames.com have the greatest urgency? Can we arrange them into High, Medium, and Low categories? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 20
  • 22. 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? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 21
  • 23. Planning Poker - Does It Work? Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 22
  • 24. 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 Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 23
  • 25. 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. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 24
  • 26. Understanding Velocity: The rate at which a team can produce working softwareMeasured in non-time-referent terms (e.g., Story Points) per SprintMore accurately stated, it is measured in terms of the stabilizednumber 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 Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 25
  • 27. 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. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 26
  • 28. Connecting The Dots: Size (complexity) is estimatedA story is estimated to be 3 story points in relativecomplexity Velocity is measured“Team A can deliver 20 story points in a 3-weeksprint” 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.” Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.
  • 29. In Other Words... Backlog Item estimates answer thequestion “how big?”, rather than “how long?” Size estimates and observed Velocity,used together, are answer the question “how long?” Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.
  • 30. Five Levels of Agile Planning:• A great place to start is by analyzing the levels of Agile Planning and assessing if each party played in their respective sandbox. Product Vision Yearly by the product owner Product Roadmap Bi-yearly by the product owner Release Planning Quarterly by the product owner and team Iteration Planning Bi-weekly by the team Daily Planning Daily by the team and individuals Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 29
  • 31. Vision & Strategy✤ Executives & high level managers are responsible for creating & adhering to a corporate or more global vision.✤ Product Owners & other managers with the help of executives form the strategy to achieve the vision.✤ The team is responsible for doing everything possible to execute on the vision by completing the work from a rank ordered product backlog.✤ The Strategy is the most overlooked portion of the project preparation.✤ Without both a vision & strategy the project will certainly fail. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 30
  • 32. The Product Roadmap:✤ The Product Owner: ✤ Helps determine when releases are best needed. ✤ Determines what functionality will be sufficient. ✤ Focuses on value derived from the release✤ The Delivery Team: ✤ Sees the entire vision in consumable chunks. ✤ Learns about next plausible steps. ✤ Learns the business priorities. ✤ Provides technical input to the roadmap. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 31
  • 33. Value of Rapid Release Planning:✤ Allows for planning for a series of iterations at a high level, reducing waste in planning detailed tasks for requirements we are uncertain about.✤ Allows for communication of the entire scope of the release to project teams and stakeholders around a high level plan.✤ Protects the ability to remain flexible and ‘agile’ by embracing changes in requirements.✤ Serves as a guide, a baseline, and is expected to be updated based on collaboration and the emerging product. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 32
  • 34. Value of Release Planning Realized:✤ Understand the need for human and other resources as the macro release level; understand possible decision points for make vs. buy, integration, etc.✤ Provides the customer and leadership with an idea of how a large project is progressing.✤ Involves the team in its creation, which means more buy-in, accuracy, and empowerment.✤ “I know things in a project are going to change, but in my agile projects, I know this information much sooner which allows for good decision making.”✤ ~ Joe CEO Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 33
  • 35. Sprint Planning - Six Steps✤ 1) Schedule items into a sprint making certain not to exceed the teams projected velocity. (If you did Rapid Release Planning, this step is done)✤ 2) Review Team member capacity to ensure that people will not be over allocating themselves.✤ 3) Detail Planning - Breakdown the work into tests and tasks. (No estimating or signing up for the work should take place during this step.)✤ 4) Member Planning - Allow team members to sign up for the work they choose and give an estimate in hours as to how long each task will take to complete.✤ 5) Review open issues and impediments that may put any item in the sprint at risk. Replace items as needed with approval from the product owner.✤ 6) COMMIT to the sprint as a team! (Let’s do this!) Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 34
  • 36. The Daily Standup Rules:✤ Daily 15 minute or less ✤ Do not be late... meeting ✤ Fines go to a reputable charity✤ Same time same place everyday ✤ Team stands in a circle✤ No problem solving ✤ Chickens around the outside✤ * No Electronics of any kind ✤ Chickens follow the same rules✤ No pen and paper to record ✤ Stick to the three questions✤ Team rules posted on the wall ✤ Always end on time Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 35
  • 37. Sprint Review✤ The team meets with the product owner to validate any work that was not marked as accepted during the sprint cycle✤ The product owner often asks to see the working product to validate that it meets acceptance criteria and is ready for demo Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 36
  • 38. Sprint Demo ✤ The team presents what it accomplished during the sprint. ✤ Typically takes the form of a true demo displaying new features and architecture. ✤ All interested parties can attend ✤ No Powerpoint or Remote Desktop for the demo. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 37
  • 39. Importance of the Demo✤ Always start with a list of incomplete features. This helps maintain trust by not hiding undone work.✤ Show all of the completed work an accept feedback on the outcome.✤ The team & customer should have a chance to respond to delivery.✤ The end goal is collaborative decision making about the future of the product. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 38
  • 40. Sprint Retrospective ✤ Inspect & adapt at the end of every sprint. ✤ Attended by the team, ScrumMaster, and Product Owner. ✤ Facilitated by the SM or other objective third party. ✤ ScrumMaster prioritizes improvements based on team direction. ✤ The team devises solutions to the most vexing problems. Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 39
  • 41. ✤ You now hold the keys to success!✤ You have been educated and empowered.✤ Visit often and drink from the well! http://www.agiledad.com/ Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 40
  • 42. Thank You! Lee@AgileDad.Com- Twitter @AgileDad - LinkedIn leehenson@gmail.com Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 41