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.
Velocity is perhaps the most useful metric available to agile teams. Mike Cohn looks at advanced uses of velocity for Agile planning under special but common circumstances. Learn how to forecast velocity in the complete absence of any historical data. You will look at how a new team can forecast velocity by looking at other teams and see how to predict the velocity of a team that will grow or shrink in size. Most importantly you will learn to use of confidence intervals to create plans we can be 90% confident in, even on fixed-price or fixed-date contracts.
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.
Estimating and planning are critical to the success of any software project, also in the case of distributed agile development. Research has acknowledged that conventional agile methods need to be adjusted when applied in distributed contexts. However, we argue that also new tools are needed for enabling effective distributed agile practices. This article presents eConference3P, a tool for supporting distributed agile teams who applies the planning poker technique to perform collaborative user story estimation. The planning poker technique builds on the combination of multiple expert opinions, represented using the visual metaphor of poker cards, which results in quick but reliable estimates.
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.