Agile Estimating and Planning Q&A

During our recent  Agile Estimating and Planning webinar, we received many fabulous questions, and we were thrilled by the energy and engagement of the participants!

Unfortunately, we were unable to answer all of the questions during the scheduled webinar. So, here we are providing answers to many of the submitted questions that we didn’t have time to answer during the session, grouped by topic.

Getting Stories “Ready”

Question 1: When getting a story “ready” are the tasks to get the future story ready, stories?
Question 2: So when do you actually do that external work to be ready? Is that an
earlier sprint/iteration?
Question 3: How do you plan and estimate effort to make stories “Ready”?
Question 4: You talked about refining story points as uncertainty is reduced. How is the uncertainty reduced – through requirements gathering? if so, how do you estimate this effort?

Answer to Questions 1-4: Usually teams work one iteration ahead to get the stories “ready” for the next iteration, so those preparation tasks should be identified and estimated during iteration planning and added to the iteration plan, although they will not be associated with a story that is being developed in the current iteration.

Although there is not a BA role per se in Scrum, many teams are using someone with BA skills to do these types of tasks, since they involve business analysis work, and the Product Owner’s time is usually constrained.

By the way, Watermark is offering a webinar on Agile Business Analysis in February if you are interested in this topic.

***

Question 5: Traditionally in the waterfall methodology, reviews or inspections are a formal way of checking for requirements quality and removing requirements defects.  What is the best way to review the quality of the requirements in Agile?  It doesn’t appear the most formal inspection process seems to line up with agile, where requirements/user stories aren’t always formally documented in that level of detail.

Answer to Question 5: In the webinar as in our course on Agile Planning and Estimating, we discussed getting stories “Ready” for development, and you can define criteria for Ready – how do you know a story is defined well enough to be developed, which is very similar to the requirements review or verification process in that you are making sure that the requirements can be used as the basis for future work. The acceptance criteria are part of the requirements validation process – how will the users know the story has been implemented correctly and meets their needs?

Time Spent Estimating and Planning

Question 1: Are there any rules of thumb on how much effort or days should be spent estimating Agile work?
Question 2: How much time do you typically set aside for an iteration planning meeting?  Do you include it as part of the iteration, e.g., within the 10 days, or as an event that happens in between iterations?

Answer to Questions 1 & 2: All of the meetings in Scrum are time-boxed based on iteration length – for a two-week iteration the iteration planning meeting is time-boxed to 4 hours or less. Iteration planning occurs on the first day of the iteration, and is part of the iteration. Release planning can take longer depending on the length of the release, but it’s a good idea to set a time box for it as well.

Agile for Financial Applications

Question 1: Waterfall seems like the only way to develop financial calculations. How do you apply Agile when developing financial software?
Question 2:We develop an EHR for the Long Term Care industry, think Skilled Nursing Facilities and Assisted living. One of our questions is how to apply Agile to the financial software development. As you can imagine, when dealing with billing, there is a specific calculation that must be used to derive the final answer. So if I need to calculate the Medicare bill there is a known calculation that must be used. It seems Waterfall works better for financial development. Is there a good way to use Agile for financial software development?

Answer to Questions 1 & 2: You can use Agile for financial applications – if you have a user story you are developing that involves a financial calculation, then part of the acceptance criteria for the story can check that the calculation was performed correctly. In this case, the calculation might affect several user stories, and can be part of the acceptance criteria for each one. Since you are testing the stories in each iteration, it is easier to find problems with the calculations and fix them earlier in the lifecycle, rather than testing for them at the end as in the Waterfall process.

Project Management and Agile

Question 1: I’m really curious about the relationship of project management to agile programming, particularly Scrum. Is the common practice for the PM to function as the ScrumMaster, or is traditional PM layered on top of the Scrum process? It is my impression that Scrum has no PM function.

Answer to Question 1: PMs often become ScrumMasters when an organization switches to agile. The role is different though – that’s why it is called ScrumMaster (CSM) rather than PM! The traditional PM role tends to be directive – assigning tasks, monitoring tasks, directing the efforts of the team.

Teams in Scrum are self-managing – they identify and estimate the work that needs to be done, and manage it. So the CSM role is much more of a coaching role. If you come from a traditional PM background and the team is new to Agile, it is very tempting to jump in and start directing them, but if you do, they won’t learn to self-manage, which is a very important part of the Agile process.

More Agile Estimating and Planning Questions

Question 1: Do you have Business and IT resources in the planning poker session?

Answer to Question 1: The business representative is there to answer questions about the stories, but should only participate in the estimating if they are also doing the work of developing the stories – basically only those that do the work should estimate.

Question 2: Doesn’t forecasting by capacity overlook discrepancies in team capabilities? I.e., you have dedicated developers, testers, and analysts. Don’t you need to estimate tasks according to available resources?

Answer to Question 2: You can break down your capacity forecast by role – developer capacity, tester capacity, etc. But remember that agile teams are meant to be cross-functional, so the idea of a dedicated role is counter to that. For example, maybe most of the time I do development but if all the development tasks are finished and there is a testing bottleneck, then I can work on testing.

Question 3: How do you address estimating on Story Points for Agile newcomers? Isn’t it easiest / more straight-forward to use Ideal Days since it’s a more “tangible” concept?

Answer to Question 3: Yes, many new teams use ideal days because they are easier to understand.

Question 4: Would you ever recommend demos each week?

Answer to Question 4: In Scrum, there is a formal demo at the end of the iteration, but I encourage people to demo early and often informally to make sure you are creating something useful for the users.

Tell Me More!