Why do so many IT projects fail? And what can we do about it? Most companies and organizations know (or at least have heard) that they should work in a more Agile manner. But it’s generally a hard sell to the people in charge. This talk dissects the Agile practices from an economic standpoint, showing that it actually makes business sense even if the project itself was to fail.
This presentation discusses an experience with lightweight planning for a team in a big company. At the heart of it is a kind of story map, a single-page plan of sorts. It is a simple tool for discovery and continuous planning with stakeholders, including what’s a minimum viable first version to go live with.
User stories are often misunderstood as small bits of requirements that help postpone analysis, but that’s not what adaptive planning should be about. Adaptive plans help organisations turn a changing landscape into a competitive advantage, react faster than the market and accelerate product discovery.
How to reduce the time needed in Agile planning? How to establish commitment of delivery without evaluating all requirement in detail? This presentation provides an introduction to planning horizon statistical method that is being used in Brno engineering center successfully for number of releases.
If the Agile Manifesto prefers responding to change over following a plan, it is not against planning. In this article, Raju Kidambi explains why it is important to use Scrum during the pre-project planning phase.
This presentation will help you understand what it takes to run a successful agile release planning meeting. The release planning is the “pacemaker” of enterprise agility and the Agile Release Train (ART) which aligns the Agile program to a common mission. Based on nearly a decade of experience, Dean Leffingwell and Scaled Agile have developed a process which has worked with small trains of 40 people to larger trains of 180. This video explains what it takes to run a successful Agile release planning meeting from a scaled point of view (100′s of teams).
User stories and their size are often the basis for planning a Sprint in Scrum. You can use a relative estimation and planning poker or a more classical approach to define the effort for each user stories. As such, they are also the basis for the metrics of progress and the velocity of the Scrum team.