If Agile approaches are tools that allows to deal with uncertainty and change, they have often little impact on the management mindset that still requires to have deadlines proposed with software development projects. In this blog post George Dinwiddie discusses the usage of user stories for planning in Scrum projects.
In this article, Christophe Le Coent discusses how you can express a Scrum product backlog to provide enough planning information to management but still following the Agile principle that “welcome changes over following a plan”.
How do agile projects accurately forecast their budget when they are typically just a bunch of hippies coding without requirements or documentation? Waterfall projects are obviously much better at budgeting with all of the traditional up front design and planning, right? Anyone who has been on a waterfall project can see that this is a complete fallacy.
In this article, Vaidhyanathan Radhakrishnan discusses about the value of release planning in Scrum. This is the tool to schedule timelines for a project or a product in a complex environment where the outcome of one team is required for the other teams. The article proposes an approach to produce a release plan. This approach is based on the finding primary and secondary features in the product backlog. You can then determine whether the resources are adequate and what interdependencies exist to adjust the feature layout. The article presents the advantages of a release plan and the common disadvantages of this situation, like including ongoing or generic activities spread across the timelines which dilutes the focus of the plan.
When you explain the iterative/incremental nature of Agile, most people coming from a waterfall lifecycle say “What? No up-front planning at all?” Some Agile coaches would glibly say yes, but the truth is more complex. Sprint Zero is an Agile term for a time-boxed amount of up-front planning. During Sprint Zero, you identify value stories, get a decent backlog of user stories and you do some architectural proof-of-concepts. The trick is to balance between insufficient planning and analysis paralysis.
This short presentation explains why software metrics are not the panacea that we thought they might be 20 years ago. This is why moving from a predictive model to a reactive approach is the only rational course.
Mike Cohn wrote an interesting post where he discusses he allows or even encourages to estimate with story points as large as 20, 40, and 100. He explains that they are useful when you need first and not necessarily precise estimate of the general size of a new project being considered.
Scrum Expert Copyright © 2009-2024 Martinig & Associates