In an effort to improve their planning efficiency, Agile teams utilize leaner, lighter written requirements to document the needs for their product. This approach allows teams to focus on creating effective, working software sooner, but also presents a challenge for these teams when they are required to effectively size their project work and predict when they will complete their development. In order to address this dilemma, Agile teams must employ an enhanced estimation technique that allows them to evaluate the level of effort required to deliver their product.
On Tuesday, May 22nd, Tom Wessel presented the web seminar “Enhanced Agile Estimation Techniques.” Tom discussed the methods today’s Agile teams use to solve the common problem of creating estimates when the complete set of requirements are unknown. Below you will find a link to the recording of the presentation as well as a written transcript of the Q&A portion of the seminar.
Want to learn more about Agile software development methods? Gain real-world, hands-on experience in one of ASPE’s Agile training courses.
Recording
Listen to the recording of it in its entirety by clicking View Event Recordings (at the top right).
Q&A
Below are some of the questions asked by participants in Tom’s web seminar. Was your question not answered? Leave your comments or questions for Tom in the comment box at the end of the post.
1. What is the best estimation technique that can be used when you have teams across regions and timezones?
Relative Estimation is the best estimation technique for estimating the total work effort of a story regardless of location. For teams that are distributed, you can use a bridge line and an online planning poker tool located at http://www.planningpoker.com/. This allows folks to share their estimates in a virtual way just at they would if they were collocated using us physical planning poker cards.
2. How do you factor defects into the estimates?
Defects should be prioritized and estimated along with Stories in the backlog. You can use the same approach to size defects by using story points and planning poker.
3. In general, what is the best way to incorporate Earned Value Management?
There are multiple ways to apply EVM to Agile. I have provide links to two similar, yet different approaches on how to do this:
• http://www.agilekiwi.com/EarnedValueForAgileProjects.pdf
• http://www.infoq.com/articles/agile-evm
4. Do you recommend that people stick to Waterfall during initiation and planning phases, Agile during requirements and build, then back toward Waterfall for Go Live and Close?
No. Rather than use Waterfall during initiation and planning, adopt the 5 levels of agile planning. This allows for planning to occur both at the macro and micro levels of the project – from Product Vision to Roadmap to Release Planning to Iteration Planning to Daily Planning. Below is a link that provides an overview of the 5 levels of agile planning:
5. So if you don’t know how many stories can be really completed in the given timeline by a given team, how do you estimate the total effort and hence cost required to complete the given project? This would be very important for the sponsor of the project.
I would use story points to estimate each story in the backlog first. I would then use the historical, average velocity of the team that will do the development to determine roughly how many sprints will be needed to complete the work. If the team does not have a historical, average velocity, then they will need to estimate their velocity. This can be done by selecting the first story in the backlog, decomposing it into tasks and then determining if they can get it accomplished in the first sprint. They repeat this process for each story until they cannot commit to any more stories for the sprint. This becomes their velocity estimate and can then be used to project the number of sprints it will take to complete the backlog.
6. How you will sign a contract based on story points instead of man-days/dollars? Any advice from experience?
Please see the response for Question 5. Once you determine the total number of the story points needed for the project and the average velocity of the team, you can then determine the projected cost of the project. Since the resources for a sprint are fixed, you can calculate the cost of each sprint and multiple that by the number of sprints. You may then want to facture in a buffer to account for unknowns.
7. Do you have any suggestions for some good books/courses to learn more about Estimation Techniques?
Yes. Many books contain chapters on Agile Estimation. However, the book that has become the standard for estimation is Agile Estimating and Planning by Mike Cohn. You can visit Mike Cohn’s web site, mountiangoatsoftware.com, to download slides on this topic.
8. Any words of wisdom for estimating a large project that we need to request budget dollars for about one year in advance?
This is difficult to do since what you budget for a year in advance will most likely change when it finally gets underway. However, you can make the most of it by estimating what you now about the project today using the technique described in Question 5.
9. Who creates the Acceptance Criteria?
The Product Owner, or proxy, is responsible for defining the acceptance criteria for a story.
10. Executives like Agile, but not relative sizing. How do you suggest gaining executive acceptance when senior people want to know what the exact project cost will be?
I believe the first step is “educate” the executives that time and energy spent doing detailed estimation for projected project cost will yield no better results than using Relative Sizing and by doing so is just wasting time and money. There is a law of diminishing returns associated with estimation when you do not have enough information to do detail estimation. A recommended approach is to determine the SPs for each story in scope for the project to generate the total number of SPs for the project. You then determine the resource cost per sprint. Using a team’s average velocity you can then determine the number of sprints needed to complete all of the stories in the backlog. You would then need to figure in the cost of additional things, such as hardware, software, travel etc. to come up with an estimate for the project.
11. What are your thoughts about 3-tier story sizing estimation?
I think this is a great approach when managing work from the Portfolio to Program to Project level. Corporate initiatives (investment themes) are implemented by Features. These are coarse grain, high level items used for Product Road Mapping and the SP sizing is a very rough estimate of the total effort. As Features get broken down into Epics and then stories, each progressive refinement results in more granular SPs estimates that can be used for Release and Sprint Planning.
12. Should you review your story points to total estimated hours?
Ideally you shouldn’t correlate SPs to Hours. For example, 1 SP = 2.3 hrs. However, you may want to review why a story that was assigned a low SP number, such as a 2, took much more effort in actual hours than originally estimated. This could help you better understand that your original estimate of a 2 for the story should have been more like a 3 or 5 relative the actual effort of other stories. Doing this may help you estimate more accurately in the future.
13. What will happen if a particular story is not completed on time? Is it possible to do the next story? If so, will the next story also will be delayed?
Stories should be independent from one another. If a story is blocked due to an impediment, then the team should begin work on the next prioritized story in the Sprint.
14. Should the estimate leader establish ground rules for the estimating team?
Yes. The ScrumMaster usually facilitates the session and they should establish the ground rules, such as the duration of the meeting and that the rules of the estimation process are followed. Either the team or ScrumMaster can determine what approach will be used for story estimation as long as it is consistent.
15. How do you deliver cost estimates for Agile teams?
If we assume that resources are fixed and time is fixed, then we can determine what the cost to an organization is for each iteration of development. The next thing we need to determine is how much scope can we guesstimate will be complete in the fixed project time frame. If we know the team’s velocity and the total number of Story Points in the project, we can then determine if the team can meet the deadline, exceed the deadline or additional sprints are required. If additional sprint are required, we can then determine how much that will cost since we know what the cost is for each iteration. We can even determine an average cost per story point as well. If we do not know what the team’s velocity, then we breakdown the stories intended for the first sprint into detailed estimates and to commit that number of stories points that the team believes they can commit to complete. We then use that velocity to determine how many Story Points can be completed in a sprint and the number of Story Points that they can realistically complete by the project deadline.
16. Does a person who is dedicated to QA participate in story estimating?
Yes. All team members that make up the cross-functional Scrum Team participates in story estimation. It is vital that all team members provide their input into the estimation process because each one has a unique perspective of the work effort and what is entailed.
17. What metrics can be used for reporting? What do you recommend?
One key metric to use it Commit vs. Complete. We want to track the number of Story Points the team commits to in Sprint Planning and compare that to the number of Story Points that we completed. Ideally it should be at 100%. If the Complete # is less than the Commit #, then we should ask why not all stories were complete so that we address the root cause.
18. Should the Requirement Priority be considered as part of the estimation process or addressed later in terms of User Story Slotting in the sprints/release organization?
Stories should be estimated in priority order for existing stories. News stories should be estimated on a regular basis so that the team can maintain a runway of user stories that are properly groomed for the team to plan during an iteration. The priority of the story and the size of the story are two separate things and can be used with things like risk and cost of delay to come up with a way to assess each story based on multiple criteria in order to determine priority. For example, let say we know what the business value for a story is, its size and its cost of delay. We can use these criteria to properly prioritize a story.
19. How long should the sizing phase take? Assuming the requirements are turned over on day one, what is a reasonable timeframe for turning around the sizing and determining the sprint it will fall in?
This really depends on the number of user stories that need to be sized. One approach is to time box the discussion of each story during the planning poker game. Otherwise the discussion will go on far longer than it should without adding additional value. You should start with a specific amount of time and experiment to see what works best. For example, start with 5 minutes of discussion and determine if that is too short or too long. The online planning poker game located on www.planningpoker.com has a built in timer that defaults to 2 minutes.
20. If you have interdependencies, how do you do the scheduling? Team A is dependent upon Team B & wants to deliver in June, but Team B can’t deliver until July, each team setting their own schedule based on velocity won’t work. How do you accommodate for this?
For starters, if both teams on working on the same project they should follow the same release schedule. This makes coordination of dependencies easier. Regardless of whether they are on the same release cycle, some decision making and negotiation will need to take place. One possibility is to request from Team B that the work on what is needed by Team A sooner in their release plan thus allowing Team A to finish their work before the deadline. If Team B is unable to do this, can Team A mock the required capability from Team B so that they can begin work on the feature. Once Team B delivers the actual capability needed, Team A would then need to perform some level of regression to determine if the actual capability performs like the mock capability. Another approach is to have Team A focus on other stories in that are not dependent on Team B. This is risky since it may not allow Team A to release the desired functionality for their release.
21. Our dev team can’t seem to get past needing full requirements before story pointing. Any advice?
Yes. I recommend that they receiving training and possibly coaching as to how to prioritize requirements and elaborate on them in a just in time manner. This is a difficult transition for teams that are used to big requirements up front. They need help in understanding while just in time requirements is a more efficient and effective approach in delivering value to the customer.
22. Presume that the user story has been developed and sent for build generation and later on if stakeholder/BA wants to make some changes in the same user story then, will it be right as per agile methodology?
Yes. After each iteration, we want to demo the feature the team committed to completing to the stakeholders in order to receive feedback. If the stakeholders want the story changed in some way and then those changes should be incorporated into the next sprint. If the stakeholders sees the story prior the end of the sprint and want changes made to it, in most instances those desired changes should be made in the current sprint. If, however, the changes are a dramatic shift from the original story then it may be worthwhile to wait until the next sprint to address the changes and stop work on the current story so to not impact the current sprint. That assumes that this isn’t the most important story in the Sprint. If it is, then the team can focus on making the changes but should request that something of lower priority that has not been started get pushed to the next sprint.
23. If the team develops 3 stories in sprint of 2 weeks, should the testing team test the stories developed in the previous sprint during the next sprint? Is so, then when should the developer team fix the bugs?
An important aspect of agile is creating potentially shippable code at the end of each iteration. This means that we want to develop, test and correct defects all in the same sprint. We want to minimize the delay of feedback to the team. The longer the time between development and testing occurs, the longer the feedback cycle and the more costly the project.
24. How do you deal with deletion of user stories that are part of a current sprint?
Assuming that the Product Owner wants to delete the story from the sprint since it may no longer be relevant, the team should pull a high priority story planned for the next sprint.
