On Thursday, August 9, 2012 Tom Wessel, presented the web seminar “How to Estimate in Agile.” In this one-hour web seminar, Tom discussed the method today’s Agile teams use to solve the common problem of creating estimates when the complete set of requirements are not known.
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.
Recording:
Listen to a recording of this web seminar in its entirety by clicking View Event Recordings (at the top right).
Remaining Questions:
Do you ever modify the priority? For example, story b gets pushed to iteration 2. Would you move 3pt Story E into iteration 2 and leave story D for Iteraition 3? You don’t modify the priority but would move a higher priority story form one Sprint to the next if the Agile Team does not have the capacity to commit to it. Your example above is correct. If the Agile Team has a 3 point capacity remaining for the current Sprint, it makes sense to move Story D to the next Sprint and move Story E to the current Sprint. The priority doesn’t change for the story. We are just optimizing productivity.
How do you plan for changes requested by the client after they see a release? That is, Story A is released but client would like changes. How do you handle this? Once Story A has met its Definition of Done, it can be shown to the customer during the Iteration Demo. This is an opportunity for the Agile Team to receive feedback. If the customer has feedback on refining the Story, a new User Story is created to address the changes.
Is there a risk of team members starting to collude points with hours? Yes. This is a common issue as team members sometime struggle working with a unit less approach. They are used to using a time-based approach. It is strongly recommended to resist the temptation to associate a Story Point to some time duration. The reason for this is that the purpose of Relative Estimation is to determine a ‘rough order of magnitude’ of the total work effort. Associating a time duration to a User Story at this point is premature since not enough information is known about the User Story to truly determine duration. That occurs during Iteration Planning.
Why do you not want to use the word sprint? The reason for this is that many webinar attendees may not be using Scrum. The term ‘sprint’ is specific to the Scrum methodology whereas the term ‘iteration’ is generic and pertains to agile in general.
Because user story is functional – have difficulty in non-functional ‘stories’ apppropriated/applied to each story. Like building rooms and levels in a house – but first priority is given to the foundation, landscaping which no one story ‘owns’? You can create technical stories (sometimes called foundational stories) that address architectural related work that must be done first before user stories (customer value related stories) are delivered. A project implementing either new architecture/technology or enhancements to existing architecture/technology would use the initial Sprint or two to vet through the architecture. Once the major technical risks have been addressed, the focus of future Sprints can change to User Stories. When vetting new architecture or technology, it is common to use what is called a spike. The purpose of the spike is to allocate time to learn about the technology so that learning can pay dividends later in the project and reduce technical risk.
Difference between epics and requirements? Epics are requirements. The term is used to defined coarse grain requirements that cannot be completed within an Iteration and need to be decomposed further. Whereas a User Story is a finer grained requirement that can be completed within an Iteration.
Please recount the 5 levels of Agile programming. There are: Vision Planning, Roadmap Planning, Release Planning, Iteration Planning, and Daily Planning
Recommended books? Agile Estimation and Planning by Mike Cohn
Do all team members do story point estimating? Some are going to be more technical, others not. Are there any ‘gotchas’ there? All members of the Agile Team, excluding the ScrumMaster, participate in story point estimation. It is key that each discipline involved in the creation of the work estimates the work so that estimates are complete since they encompass each disciplines perspective.
What do you think about breaking stories that are nto complete and credit whatever are done to the current sprint, i.e. a 5 points story into 2+3 crediting 3 to the current sprint and moving the removing 2 points story to the next sprint? It is recommended to not do this. The team should establish an agreed upon Definition of Done. They should then measure each story in the Iteration against whether it met the Definition. If not, then they should get no Story Point credit for it. This is important for two reasons. The first is that we are interested in average velocity over time. If the team is able to complete the work in the next Sprint then the average velocity is not impacted. The second thing it does is reinforces the notion that the team completes the work that they commit to. By taking partial credit for partial work may encourage the team to think it is acceptable to not complete all the work they committed to. We want to complete work in the Sprint so that we can move on to new work in the next Sprint.
How you deal with team members taking vacation during each iteration? Less team members will affect the team’s velocity. Usually we don’t know who will take vacation until sprint planning. Part of the Iteration Planning process is to take into account team member availability for the current Iteration. This includes vacation, other project work, meeting overhead, etc. If the team is without a team member or two for part of the Sprint, this will impact their velocity and this should be accounted for in the number of Story Points they commit to. Keep in mind; we are interested in the team’s average velocity, which will help smooth out fluctuations in the velocity that are Iteration specific.
If we start a fresh project and totally new to the technology and its a totally new team. How can we best achieve the initial very first estimation? Please remember, no one in the team has no understanding on user story requirements. Thank. The first step is to receive training on how to create and manage a backlog and create, estimate and prioritize user stories. Once the team has those concepts down, they should then determine their initial velocity in the following way. The team determines their capacity in hours for the sprint. This is done by adding up everyone’s available hours for the Sprint. For example, if you are working in a 2-week cycle each person has 80 hours of time. You subtract time for each person based on Scrum meeting overhead, say 8 hours, and then any vacation, other project work etc. As a result, a fully dedicated person on the project is available 72 hours for the Sprint.
Select the first story and decompose it into atomic tasks with hour estimates. Once complete, have the team determine if enough capacity is remaining. If so, continue this process until the team runs out of capacity. This is the team’s baseline velocity for planning. Reality will kick in at the conclusion of the first Sprint once the Team determines what Story Points they actually completed. That then becomes the team’s new baseline velocity for planning purposes.
The LEAN community is advocating to break stories down so fine that they’ll al fit within a 1 to 1 1/2 day work and postulate the estimation is longer necessary; what are your thoughts on that? That is a good approach. I have seen stories range from 1 to 3 days.
What ratio of people we should keep for development and testing in agile environment? This depends on the unique aspects of the project. I would imagine a 1-1 or 2-1. Keep in mind that Agile will require more automation in order to keep up with regression. This may increase the number of QA team members.
How many sprints or iterations in an “average” size project? There really is no “average. Each project is different in terms of time duration and the size of the sprint length the Agile Team finds optimal.
As you get better about sizing, do you ever re-estimate the story points for stories further down the roadmap? Yes. Don’t re-estimate stories that you have completed. Move on. However, you may re-estimate stories if there is value in doing so based on new information that may dramatically change the relative work effort.
At what point and how do you turn time/effort into staff numbers and budget dollars? In Agile, we invert the project management iron triangle (scope, time, cost) where Scope is fixed to fixing time and duration and making Scope variable. This is done by fixing the cost (team) and the time (fixed length iterations). We can then determine the cost per iteration. We determine the number of iterations needed by sizing each Story in the Product Backlog and establishing a baseline velocity. This allows us to create an initial Release Plan. The Release Plan is then updated after each Iteration based on the # of Story Points completed and the # of remaining Story Points and the updated average velocity of the team.
How do you incorporate capacity for bug fixing? Or is that completed before starting the next iteration? Defects, like Stories, are part of the Product Backlog. As such, they should be prioritized and sized just like User Stories. The reason for this is that correcting Defects takes time away from the Agile Team’s capacity and this should be tracked and accounted for.
