Q: Our business asks how much would it cost to do X and in how much time.
A: Agile can be viewed that way because it does require buy-in from the upper levels of the organization to allow the team to take ownership of projects, and establish their working cadence first. It's a common pitfall for those looking to transform to agile. Read more here.
Q: Why do you suggest to estimate spikes in points? Spikes do not bring business value. What are your thoughts on this?
A: Because it is still work that the team has completed. If you have a 2-point spike, and the team averages 20 points of velocity per iteration, a chart may show 18 points of completed work. That negatively affects velocity, which is incorrect. The team did gain value by learning more about the proposed feature.
Q: Is it okay to split stories during estimation with the team?
A: By split do you mean break the story down from extra large to a group of smaller stories? If so, yes. The moment the team determines that a story is larger than an entire iteration work of velocity (but keep going, break them down as small as possible), the story should be broken down.
Q: What is best practice for planning poker when the team members are globally dispersed? Video meetings?
A: You can use video, instant messenger, or phone conferences to perform planning poker or other estimation techniques.
Q: I find people try to correlate the size based estimation into days and hours, and they do that by using the tasks feature. How do you get the team not to correlate tasks to size-based estimation?
A: Focus on making story points abstract. Correlate the size of new work to similar work the team completed in the past. Emphasize that such correlation is useful, but only after an iteration is complete, to verify and adjust estimates, instead before the iteration is complete.
Q: Is a Scrum Master generally a full time position? It seems like a potential full-time job during planning and retrospective, but not for the full 2-4 weeks of an iteration when programmers are programming. Beyond daily scrum meetings, what does the scrum master do?
A: Generally, yes, it is considered a full time duty. Scrum masters help to unblock team members from issues in their way, represent the needs of the team to the business, and facilitate meetings. Meetings include the daily stand-up, iteration planning, release or long-term planning, backlog grooming and estimation, and retrospectives. If you have multiple teams, a scrum master can serve on both.
Q: Why is it okay to convert points into cost but not points into hours?
A: Hours is a much more granular estimate, and shouldn't be relied on to provide cost. With points, you know generally if you're going to meet your iteration commitments. Task hours represent the daily commitments, and can be used at the end of the iteration to see if your point estimates are accurate.
Q: How can you estimate project duration when you have the stories and their relative size but the delivery team is co-located and hence no planning poker?
A: If the delivery team is co-located, you can still perform group estimation activities so that you can compare the proposed work against the team's velocity. Using phone, video, conferencing software, CA Agile Central, and instant messenger, you can make your agile team room global, allowing for planning poker or other methods.
Q: I have a large project with multiple scrum teams. How important is it that all teams size the same?
A: If the teams coordinate together to deliver work, it is very important that the teams use the same sizing system. Here at CA Agile Central, all of our half dozen (or more) development teams use the same sizing practice: a chart with well-known past stories with corresponding point values is displayed in work areas. Teams can coordinate by having discussions like, "This new feature looks to be the same size and complexity as past feature X, which we know is a 5 point story. This is 5 points."
Q: Does size relate to the number of resources working on a story?
A: It relates to the team as a whole and their belief in delivery. That doesn't mean every team member works on every story in an iteration, but during estimation and planning meetings, discussions can take place that uncover skills and needs of individuals.
Q: I support multiple teams as a tech writer. How do I protect my work time when there seem to be many meetings?
A: Story points are relative, while task hours are fixed. However, you only have so many hours to work in a day. These hours are known as your capacity. During planning meetings, after stories are scheduled, tasks are presented. You can alert the team if the tasks proposed for your writing work exceed your total number of hours available for all teams in the current iteration. Speak to your scrum master about finding ways to make your time in meetings most valuable. For example, you can ask that some teams talk about stories that need documentation first, so you can provide your input, then move to another team's meeting.
Q: How do you deal with specialized expertise on a team when estimating story points? For example, to most engineers, a story may have 20 points, but to a select few, that same story may be 3 points?
A: It may be that the team is thinking in absolute terms, instead of comparing the story to past work.
Q: Do you suggest providing estimates in days once we separated them in small , medium, and large? How many days maximum do you suggest before a feature needs to be broken down?
A: No. Estimates should always be an abstract and relative value. If you give into the temptation of correlating a certain number of user story points to actual days or hours, you risk falling into the tendency to underestimate.
Q: What is the proposed best practice for developing velocity and burndown charts for different teams on the same project?
A: One suggestion is to use tags in CA Agile Central, so that you may take advantage of the Story Burndown charts. This allows you to track all work across multiple projects, over the course of iterations and releases.
Q: When teams are voting on points, some vote for more points because of a learning curve and the more experienced developers vote for less points. How do you handle that?
A: Planning poker.
Q: How are estimates for stories transferred to points?
A: Points represent how much work is involved in each story. Better to represent in points rather than in hours.
Q: How do you estimate accurately when there are several dependencies affecting the tasks of a user story?
A: Those dependencies should be uncovered and discussed by the team during meetings. Such dependencies increase the complexity of work, which can increase the initial story estimate.
Q: CA Agile Central has tasks which ask for hours, days, and type of estimate. And I find it difficult to get the team to do size based estimation because of this. So why have those tasks?
A: User stories are estimated by the team, with the relative, abstract value of points. After a team commits to those stories, tasks may be used to help individuals provide short-term estimates as to their ability to complete steps to bring that user story closer to completion. This can be done in hours, to ensure a team member has enough capacity during the week to handle the work load. See the Sizing and Estimating video from a coach for an explanation of the difference between the two values.