Agile Project LifeCycle
- 1. Agile Project Life Cycle Shaun Smith This document contains the proposed project life cycle
- 2. Table of Contents Why Agile Project Management Works…………………………………………………………….………………………………………………………4 Product Owner…………………………………………….………………………………………………………………………………………….……………….4 Planning Levels…………………………………..…………………………………………………………………………………………………………………….4 Create a SharePoint 2010 Project Management Information System Template…………………………………………………………5 Stand-‐Up Meetings……………………………………………………………………………………………………………………………………………………6 Implement Version Control through SharePoint 2010……………………………………………………………………………………………….6 Project Budget………………………………………………………………………………………………………………………………………………………….6 Estimating Size and Effort…………………………………………………………………………………………………………………………………………6 Key Points When Estimating in Story Points………………..…………………………………..……………………………………………………….7 Planning Poker for Release Planning…………………………..…………………………………………………………………………………………….7 Velocity Equalizer………………………………………………………….………………………………………………………………………………………….8 Planning……………….…………………………………………………………………………………………………………………………………………………..8 Planning for Value……………..……………………………………………………………………………………………………………………………………..8 Prioritization…………………………………………..………………………………………………………… ……………………………………………………..9 Knowledge………………………………………………………………………………………………………………………………………………………………..9 Risk……………………………………………………………………………………………………………………………………………………………………………9 When to Split a User Story……………………………………………………………………………………………………………………………………...10 Scheduling……………………………………………………………………………………………………………………………………………………………….10
- 3. Release Planning……………………………………………………………………………………………………………………………………………………..10 Sprint Planning………………………………………………………………………………………………………………………………………………………..11 Velocity-‐Driven………………………………………………………………………………………………………………………………………………………..11 Commitment Driven…………………….………………………………………………………………………………………………………………………….12 Burndown Chart………………………………………………………………………………………………………………………………………………………12 User Stories…………..…………………………………………………………………………………………………………………………………………………12 Appendix A: (Agile Model)……………………………………………………………………………………………………………………………………….13
- 4. AGILE PROJECT LIFE CYCLE Why Agile Project Management Works Table of Contents 1. A plan does not guarantee an exact set of features on an exact date at a specified cost. A plan does, however, communicate and establish a set of baseline expectations. 2. A plan should be updated regularly throughout the course of the project, so that something like a one-‐ month late delivery will not be a last-‐minute surprise to anyone. 3. Agile planning balances the effort and investment in planning with the knowledge that we will revise the plan through the course of the project. 4. An agile plan is one that we are not only willing, but eager to change. 5. The planning becomes more important than the plan. 6. You do not have to change the dates, you can drop a feature, reduce the scope of a feature, add people to the project. 7. Completed features are the unit of customer value, not completed activities. 8. The estimates we give should reflect our uncertainty. The way to do this is by expressing the end date as a range. 9. The best way to deal with uncertainty is to iterate/sprints. 10. Frequent re-‐planning after each sprint. 11. For a plan to be useful, it must be accurate, but agile accepts that early plans will be imprecise and will need to be re-‐planned to remove the imprecision. 12. Agile estimating and planning succeed because estimates of size and duration are separated. We start by estimating the size of a project through user story points. Then estimate a rate of progress called velocity. The estimate of size and velocity are then combined to arrive at an estimate of duration. 13. Agile acknowledges the importance of learning. Product Owner Table of Contents 1. Make sure all team members are pursuing a common vision for the project. 2. Establish priorities so highest-‐valued functionality is always being worked on. 3. Set and obtain sign-‐off criteria. Planning Levels Table of Contents 1. Day 2. Iteration 3. Release 4. Product 5. Portfolio 6. Strategy
- 5. The goal of Product Backlog planning is to determine an appropriate answer to the questions of scope, schedule, and resources for a project. A good release plan is updated throughout the project at the start of each sprint, and should be based on work accomplished in the just finished sprint, identified high-‐priority work the team should address in the new sprint. Create a SharePoint 2010 Project Management Information System Template Table of Contents Template will include: a. Libraries: i. Project Documents 1. Milestones Doc a. Chart Web Part – Milestone Dashboard b. Lists: i. Project Announcements 1. Title, Modified ii. Project Calendar 1. Connect to Outlook iii. Project Contacts 1. Last Name, First Name, Company, Business Phone, Home Phone, E-‐mail Address iv. Project Risks 1. Issue ID, Title, Assigned To, Issue Status, Priority, Due Date v. Agile Product Backlog 1. Task Name, User Need, Story Points, Start, Finish, Predecessors, Duration, State, Sprint vi. Project Resources 1. Resource Name, Cost (per hour), Notes, Role vii. Change Request 1. CR Tile, Description of Change, Affected Task, CR Status, Due Date, Change Request viii. Project Milestone 1. Title, ID Number, State = Not Started, State = In Progress, State = Complete c. Discussions: i. Discussion Board 1. Subject, Created By, Replies, Last Updated
- 6. Stand-‐Up Meetings Table of Contents Most agile teams use some form of daily stand-‐up meeting to coordinate work and synchronize daily efforts. Teams definitely make, assess, and revise their plans during these meetings. They focus on the planning of tasks and on coordinating the individual activities that lead up to the completion of a task. Implement Version Control, Through SharePoint, Table of Contents Control and track the current version of the document by using the “check-‐in” and “check-‐out” feature. This will ensure that only one team member is working on a deliverable at any one point in time. The” Check In” feature will assign a version number and capture comments describing the type of update. This will create the version history. Project Budget: Table of Contents If budget management is required for a project, it will be conducted through MS Project 2010. The two general budget categories that will be created are as follows: a. Fixed Budget Costs e.g. Hardware, Software, Travel etc. b. Computed Budget Costs for Budget Work Resources based on Cost Rates Estimating Size and Effort Table of Contents A story-‐point estimate is an amalgamation of the amount of effort involved in developing the feature. This consists of the complexity of developing the feature, and the risk inherent in its development. Story points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work. The raw values we assign are unimportant. What matters are the relative values assigned to each feature or story. For instance a feature that is assigned a two should be twice as much as a story that is assigned a one. There are two common ways to start estimating features or stories by Analogy or Triangulation. The first approach is to select a story that you expect to be one of the smallest stories you’ll work with and say that story is estimated at one story point. The second approach is to instead select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use. After you arbitrarily assign a story-‐point value to the first story, each additional story is estimated by comparing it with the first story or with any others that have been estimated. One way to do this is to assign a dog point as representing the height of a dog at the shoulder. Assign dog points to each breed below: • Labrador retriever = 5 • Terrier = 3 • Great Dane = 10 • Poodle = 3 • Dachshund = 1 • German shepherd = 5 • Saint Bernard = 9 • Bulldog = 3
- 7. When you give a loosely defined user story, you make some assumptions, take a guess, and move on. It is not uncommon to begin a sprint with incompletely specified requirements, the details of which will be discovered during the sprint. Two developers of different skill or experience can agree on the size of something while disagreeing about how long it will take to do. Ideal time is the amount of time that something takes when stripped of all peripheral activities including overall size and complexity of the feature being implemented. Elapsed time is the amount of time that passes on a clock or calendar. When considerations of organizational overhead are ignored, ideal days can be thought of as another estimate of size, just as story points are. Estimate ideal days by associating a single estimate with each user story, rather than estimating that a user story will take four programmer days, two tester days, and three product owner days, it is better to sum those days and say the story as a whole will take nine ideal days. Agile teams do not rely on a single expert to estimate. Estimates are derived collaboratively by the team, which includes those who will do the work. Studies show that people are best at estimating things that fall within one order of magnitude. Two estimation scales that can be used are the Fibonacci numbers: 1,2,3,5, and 8, or 1, 2, 4, and 8. A large user story is called an epic. A set of user stories is referred to as a Theme. An epic can be a theme on its own. Estimates of themes and epics will be more uncertain than estimates of more specific, smaller user stories. User stories need to be small enough that they can be completed in a single sprint. Disaggregation refers to splitting a story or feature into smaller, easier-‐to-‐estimate pieces. Key Points When Estimating In Story Points: Table of Contents o Story points help drive cross-‐functional behavior because they are estimated as a group. o Story point estimates do not decay because the story will always be the same size but the time it takes to complete will change. o Story points are a pure measure of size if we estimate by analogy only (this is like that). o Estimating in story points typically is faster. o My ideal days are not your ideal days because everybody will need to take as long as THEY need to complete a task. Planning Poker for Release Planning Table of Contents Planning poker, each estimator is given a deck of cards with written estimates of 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100 on each of them. The moderator reads the description. The moderator is usually the product owner or an analyst. Everyone is asked to remain aware of the effort/accuracy curve. The goal is to be somewhere well on the left of the effort line, where a valuable estimate can be arrived at cheaply. After all questions are answered, each estimator privately selects a card representing his or her estimate. Cards are not shown until each estimator has made a selection at that time, all cards are simultaneously turned over and shown so that all participants can see each estimate. If estimates differ, the high and low estimators explain their estimates. The moderator can take any notes she thinks will be helpful when this story is being programmed and tested. After the discussion, each estimator re-‐estimates by selecting a card. Cards are once again kept in private until everyone has estimated, at which point they are turned over at same time. Continue the process as long as estimates are moving closer together. Use a timer in the middle of the table and allow two minutes for each hand of poker. Estimating an initial set of user stories may take a team two or three meetings of from one to three hours each.
- 8. Planning poker works, first, because it brings together multiple expert opinions to do the estimating. These experts form a cross-‐functional team from all disciplines on a software project. Second, a lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates. Third, averaging individual estimates leads to better results. Velocity Equalizer Table of Contents Velocity is the great equalizer, because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. As long as we are consistent with our estimates, measuring velocity over the first few sprints will allow us to hone in on reliable schedule. Re-‐estimate only when a story’s relative size has changed, or when the team finishes only a portion of a story is finished during a sprint. If everything is done all points are captured, if anything is missing no points are captured. Re-‐estimate as few stories as possible to bring the relative estimates back in line. Use re-‐estimating as a learning experience for estimating future user stories. A team only counts points toward velocity for stories or features that are complete at the end of a sprint. Counting partially finished work, giving partial credit, makes it impossible to know exactly where we are in the project, and leads to a buildup of work in process. The more work in process, the longer it will take new features to be transformed from raw ideas into functioning product. Large amounts of work in process will take longer for the team to get feedback on what was completed. Planning Table of Contents Before planning a project, we must consider what it is that our users need. Individual user stories or features are aggregated into themes. Stories and themes are then prioritized relative to one another for the purpose of creating a release plan, such that themes should be selected so each defines a discrete set of user-‐or-‐customer-‐valued functionality. Release planning is the process of creating a very high-‐level plan that covers a period longer than an sprint. A typical release will cover perhaps three to six months and maybe three to twelve or more sprints. Planning for Value Table of Contents The whole team is responsible for estimating. It is difficult to estimate the value of small units. User stories or features are aggregated into themes. Stories and themes are prioritized relative to one another to create a release plan. Each theme defines a discrete set of user valued functionality. Prioritization Table of Contents Four factors must be considered when prioritizing themes. 1. The financial value of having the features. Estimate its financial impact over a period of time. New sales, new donations…etc.
- 9. 2. The cost of developing (and perhaps supporting) the new features. 3. The amount and significance of learning and new knowledge created by developing the features. 4. The amount of risk removed by developing the features. The themes with a high value-‐to-‐cost ratio are those that should be done first. When possible, try to combine related stories as that will make it easier to prioritize them. Determine the priority of a theme by asking questions such as “How would the user feel if the feature were present”, and then ask “How would the user feel if the feature were not present”. Use the following answers: 1. I like it that way 2. I expect it to be that way 3. I am neutral 4. I can live with it that way 5. I dislike it that way Dynamic Systems Development Method (DSDM) is another way of determining priority. Requirements are sorted into four categories: Must Have, Should Have, Could Have, and Won’t Have. No more than 70% of the planned effort for a project can be targeted at Must Have requirements. In this way DSDM projects create a feature buffer equivalent to 30% of the duration of the project. Knowledge Table of Contents At the start of a project, we never know everything that we will need to know by the end of the project. There is two types of knowledge that a team develops: o Knowledge about the product, (what will be developed). o Knowledge about the project, (how will it be developed). Risk Table of Contents A risk is anything that has not yet happened but might and that would jeopardize or limit the success of the project. The types of risks are: o Schedule risk (“We might not be done by October”) o Cost risk (“We might not be able to buy hardware for the right price”) o Functionality risk (“We might not be able to get that to work”) o Technological risk o Business risk When to Split a User Story Table of Contents A user story should be split when it is too large to fit within a single sprint. It won’t fit within the sprint being planned because there isn’t enough room left. Split story by the type of data that the user could enter.
- 10. Split a story along the boundaries of the common CRUD operations Create, Read, Update, Security, Error-‐Handling, Delete, and Logging. Deliver a partial user interface, a partial middle tier, and a partial database. Delivering a cohesive subset of all layers of a feature is almost always better than delivering all of one layer. Scheduling Table of Contents In some cases we start with a finish date and see how much we can finished by that date. In other cases we start with a set of user stories and see how long it will take to develop them. Multiply the planned number of sprints by either the expected or known sprint velocity of the team gives the total amount of work that can be performed. If feature driven project, sum the estimates of all needed features and divide by the velocity. This will give us the number of sprints necessary to complete the desired functionality. If date-‐driven project, we can determine the number of sprints by looking at a calendar. Multiply the number of sprints by the expected velocity will tell us how many story points or ideal days will fit in the release. The product owner selects the top priority items that will fit in the first sprint. Cards are stacked or arranged to indicate which stories comprise each sprint. Each story card is annotated with an estimate, it is possible to look down each column of an arrangement and verify that each sprint holds the right amount of work. Release Planning Table of Contents Agile planning becomes a two-‐stage process, release plan and iteration plan. The first stage is the release plan, with its rough edges and general uncertainties. Release planning is the process of creating a very high-‐level plan that covers a period longer than a iteration. A typical release is three to six months and maybe three to twelve iterations. A release plan does the following three things: o Helps the product owner and team decide how much must be done and how long it will take. o Conveys expectations about what is likely to be developed and in what timeframe. o Serves as a guidepost for progress. o Either starts with an end date and see how much can be finished, or start with a set of user stories and see how long it will take to develop them. o Multiply the planned number of iterations by either the expected or know velocity of the team gives us the total amount of work that can be performed, (Number of Iterations x Velocity = Amount of Work Performed). o Sum the estimates of all needed features and divide by the expected velocity will give the number of iterations necessary to complete the desired functionality, (Features / Velocity = Number of Iterations to Complete). o Decisions about who works on what and the sequence of activities are best left to the individuals working on those tasks and best deferred as long as possible. o Include additional information in the release, such as assumptions like who is on the team , first iteration start date, and finish date. o Place specific work into the first one to three iterations, rest of the release plan is product backlog. Sprint Planning Table of Contents A release plan provides only the high level view of the product being built. With iteration plan, a team takes a more focused, detailed look at what will be necessary to implement completely only those user stories selected for the new
- 11. iteration. An iteration plan is created in an iteration planning meeting. Anyone involved in taking a raw idea and turning it into a functioning product should be present. It can be as simple as a spreadsheet, a set of note cards with one task handwritten on each card, or eboard on SharePoint . Tasks are not allocated to specific individuals. The sprint plan looks ahead only the length of one sprint, usually one to two weeks. The sprints should be staggered with a one week sprint and then a two week sprint and then a one week sprint. The user stories of the release plan are decomposed into tasks on the iteration plan. Tasks on the iteration plan are estimated in ideal hours. An iteration review meeting is held after the iteration is finished, and will take thirty to sixty minutes. A prioritization meeting is held two days before the end of the iteration, and involves anyone that can contribute to a discussion of the project’s priorities. Two ways to plan a sprint, one is called velocity-‐driven and the other is commitment-‐driven. Velocity-‐Driven is done by the following: Table of Contents 1. Collaboratively adjust priorities. 2. Id the target velocity for the coming iteration. 3. Selects a sprint goal, what they wish to accomplish. A unifying statement about what will be accomplished during the iteration. It does not have to be very specific. 4. Select the top-‐priority user stories that support goal, enough to sum up ideal-‐day or story-‐point estimates to equal target velocity. 5. The best way to predict velocity is to observe velocity, this should always be your default approach. 6. Selected stories are split into tasks, and each task is estimated. All tasks necessary to go from a user story to a functioning, finished product should be identified. Only include tasks that add immediate value to the current project. Include tasks for meetings and any time spent preparing for the meeting. Put stories in their natural order which is the order the team assumed when they estimated the stories. A spike task included in an iteration plan that is being undertaken specifically to gain knowledge or answer a question. The spike would help the team learn how they’d approach the other task, which would allow them to estimate it. A task should be able to be completed within one day. Commitment-‐Driven is done by the following: Table of Contents 1. The team adds stories to the iteration one by one until they can’t commit to any more. 2. Adjust priorities and identify an iteration goal. 3. Estimate the number of hours that each person will be available to work on the project each day. 4. Determine the total number of hours that will be spent on the project during the sprint. 5. The product owner and team select the highest-‐priority story. 6. Stories are selected and decomposed into tasks. 7. Tasks are estimated one story at a time and converted into ideal hours. 8. Select tasks until you have identified enough tasks to fill the number of hours in the sprint. Schedule the prioritization meeting for two days before the end of the iteration. The product owner conducts the prioritization meeting and involves anyone she thinks can contribute to a discussion of the project’s priorities. Sum up the estimates and see if the sum represents a reasonable amount of work.
- 12. If a new task is discovered during the iteration (and they almost certainly will be), a team that is committed to delivering the functionality described by a user story will try to complete the new tasks as well. The key is that everyone on the team is accountable for contributing whatever is within their capabilities, regardless of whether it is their specialty. Burndown Charts Table of Contents Shows the number of story points or ideal days remaining in a project. User Stories Table of Contents Example: Front As a <> I want to <> so that I can <>. Priority: (DSDM) – Must Have, Should Have, Could Have, Won’t Have Story points: 1,2,3,5,8,13,21,34 Back Confirmations or acceptance criteria, sketches, flow charts, UML
- 13. Appendix: A ( Agile Model) Table of Contents