Question 1:<\/strong> When getting a story “ready” are the tasks to get the future story ready, stories? Answer to Questions 1-4:<\/strong> Usually teams work one iteration ahead to get the stories \u201cready\u201d 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.<\/p>\n 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\u2019s time is usually constrained.<\/p>\n By the way, Watermark is offering a webinar on Agile Business Analysis in February if you are interested in this topic.<\/p>\n ***<\/p>\n Question 5:<\/strong> Traditionally in the waterfall methodology, reviews or inspections are a formal way of checking for requirements quality and removing requirements defects. \u00a0What is the best way to review the quality of the requirements in Agile? \u00a0It 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.<\/p>\n Answer to Question 5:<\/strong> In the webinar as in our course\u00a0on Agile Planning and Estimating, we discussed getting stories \u201cReady\u201d for development, and you can define criteria for Ready \u2013 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 \u2013 how will the users know the story has been implemented correctly and meets their needs?<\/p>\n Answer to Questions 1 & 2<\/strong>: All of the meetings in Scrum are time-boxed based on iteration length \u2013 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\u2019s a good idea to set a time box for it as well.<\/p>\n Question 1:<\/strong> Waterfall seems like the only way to develop financial calculations. How do you apply Agile when developing financial software? Answer to Questions 1 & 2<\/strong>: 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.<\/p>\n Question 1:<\/strong> 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.<\/p>\n Answer to Question 1:<\/strong> PMs often become ScrumMasters when an organization switches to agile. The role is different though \u2013 that\u2019s why it is called ScrumMaster (CSM) rather than PM! The traditional PM role tends to be directive \u2013 assigning tasks, monitoring tasks, directing the efforts of the team.<\/p>\n Teams in Scrum are self-managing \u2013 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\u2019t learn to self-manage, which is a very important part of the Agile process.<\/p>\n Question 1:<\/strong> Do you have Business and IT resources in the planning poker session?<\/p>\n Answer to Question 1:<\/strong> 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 \u2013 basically only those that do the work should estimate.<\/p>\n Question 2:<\/strong>\u00a0Doesn’t forecasting by capacity overlook discrepancies in team capabilities? I.e., you have dedicated developers, testers, and analysts. Don’t you need to estimate Answer to Question 2:<\/strong> You can break down your capacity forecast by role \u2013 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.<\/p>\n Question 3: <\/strong>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?<\/p>\n Answer to Question 3:<\/strong> Yes, many new teams use ideal days because they are easier to understand.<\/p>\n Question 4:<\/strong> Would you ever recommend demos each week?<\/p>\n Answer to Question 4:<\/strong> 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.<\/p>\n
\nQuestion 2:<\/strong> So when do you actually do that external work to be ready? Is that an
\nearlier sprint\/iteration?
\nQuestion 3:<\/strong> How do you plan and estimate effort to make stories “Ready”?
\nQuestion 4:<\/strong> 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?<\/p>\nTime Spent Estimating and Planning<\/strong><\/h2>\n
![\"Agile](\"\/blog\/wp-content\/uploads\/2014\/07\/Agile-Meeting-300x199.jpg\")
Question 1:<\/strong> Are there any rules of thumb on how much effort or days should be spent estimating Agile work?
\nQuestion 2:<\/strong>\u00a0How much time do you typically set aside for an iteration planning meeting? \u00a0Do you include it as part of the iteration, e.g., within the 10 days, or as an event that happens in between iterations?<\/p>\nAgile for Financial Applications<\/strong><\/h2>\n
\nQuestion 2:<\/strong>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?<\/p>\nProject Management and Agile<\/strong><\/h2>\n
More Agile Estimating and Planning Questions<\/strong><\/h2>\n
![\"BecomeAnABA\"](\"\/blog\/wp-content\/uploads\/2015\/11\/BecomeAnABA.png\")
<\/a>tasks according to available resources?<\/p>\n