Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile development and project management


Published on

Old deck I used back in 2010 when kicking off a small Scrum project.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Agile development and project management

  1. 1. Agile Development & Project management Vishal Bardoloi
  2. 2. The Problem • Despite everyone’s best intentions and efforts, software projects continue to fail • This is in large part due to communication breakdowns • Capturing software requirements is a communication problem between two totally different “types” of people • When business dominates, it mandates functionality and timelines with little concern that developers can meet them • When developers dominate, technical jargon and “cool features” take over the real needs of the business
  3. 3. Case in point:Waterfall • In traditional waterfall methods, decision- making and information-gathering are done only once - at the beginning of the project • They take away options by making decisions earlier than they need to be made • They rely on ‘middlemen’ to communicate between developers and stakeholders • As a result, the communication process is broken on most projects
  4. 4. The Agile Solution Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  5. 5. Agile comes in different flavors... we will be using the Scrum process
  6. 6. Scrum Overview • Consists of a number of short iterations, or ‘sprints’ • Defined roles: • Product manager - the business users’ representative • ScrumMaster - facilitates the development and meetings • Development Team • Stakeholders - end users, project sponsors etc • Meetings after each iteration • Sprint review - to demo the development done in the past sprint • Sprint planning - plan the next iteration’s deliverables
  7. 7. Scrum Development • 2 to 4 week sprints • During each sprint, the team will create a set of Production-ready features • A Sprint review/planning meeting will be held after each sprint, where - • Team will demo the functionality developed in the previous sprint • Business users will prioritize the backlog for the next sprint • Team will determines how much of the requested backlog they can finish in the next sprint • No requirement changes in the middle of a sprint
  8. 8. Scrum Development
  9. 9. Scrum Roles • Facilitator • NOT a team lead (the team is self-organizing) • Facilitates user story sessions and sprint meetings • Removes roadblocks to the team’s success & protects them from distractions • Development Team • A group of people with cross-functional skills • Design, develop, test, communicate • Product owner • Writes the user stories • Prioritizes the backlog of user stories • Signs off on deliverables
  10. 10. Scrum Roles Customers Developers Agree upon the length of each sprint (this will stay the same throughout the project) Select and prioritize the user stories to be worked on for each sprint Estimate the effort for each story (in story points) Agree upon the deliverables for each sprint Specify the acceptance tests for each user story to be complete Deliver fully usable code that meets the user story requirements Make themselves available to resolve questions from the development team Identify and communicate issues early Share responsibility for the final success of the project
  11. 11. Roles: Pigs & Chicken “Pigs” are committed to the project.“Chicken” are merely involved.
  12. 12. Scrum Documents • Project Backlog • High-level document for the entire project • Contains descriptions of all the required features, prioritized by business value • Contains rough estimates of business value and development effort • Sprint Backlog • The requested features are broken down into tasks of 4-16 hours • Estimates are set by the entire team • Team members assign tasks to themselves, based on priority and their skill level • Burn Down Chart • A chart of the work remaining in the Sprint backlog • Publicly available, updated daily with status (“To do”,“In dev”,“Done”)
  13. 13. The User Story tool is used to gather requirements in Agile projects
  14. 14. • There are 3 parts to a User Story: • Card - a written description of the story, used for planning and as a reminder to have a conversation • Conversation - discussions between customer and developer about the story, to flesh out the details and define acceptance tests • Confirmation - tests that determine when the story is completed The User Story
  15. 15. The User Story Card •Created during the user story workshop •Small, independent, negotiable, testable •Meant to be high-level; serves as a reminder to have a conversation Conversation •Can occur at the sprint planning meeting or any time during the sprint • •The detailed requirements are fleshed out here, by the business user and developer working together Confirmation •a.k.a.“Acceptance Tests” - these are tests that define the user’s expectations and provides developers with a way to check if they’re done •Initially defined during the sprint planning meeting; can change during the sprint via conversations
  16. 16. The User Story • Emphasizes verbal communication over written • Spreads the decision-making process across the duration of the project • decisions are made based on the information available • decisions are made at the time when the functionality in question is being developed • Lets you defer the details until you have the best understanding of what you really need • Easily understood by both customers and developers
  17. 17. Good User Stories • A bad story: “Create an Invoice” • A good story: “As a (user role), I can (function) so that (business reason)” “As a CCR, I can search for customers by their first and last name so that they don’t need to look up their account number” “As a Retail Ops manager, I can manage my team’s privileges so that they can void/delete/ resend invoices” (Front of card) As a CCR, I can search for customers by their first and last name so they don’t need to look up their acct number (Back of card: acceptance tests) Test if multiple customers have same name. Test if customer name doesn’t exist in system. ...