Agile teams can easily get puzzled by the heated debate happening between advocates for estimation and those in the #NoEstimates camp. However, by comparing how they solve these problems, we can identify many common practices between the two groups and see they are not truly at odds—they actually complement each other. Let's bridge the gap.
Agile software development is mainstream by now, but people are still finding ways to experiment with agile. Measuring agile success with metrics, the debate over whether to use estimates, and improving predictability in Scrum were all hot topics last year. The rise of DevOps has given even more material for people curious to adopt the practice, so automation and "continuous everything" were also popular subjects.
Agile story estimation gives the team insight into the level of effort for each work item, allows the team to assess each requirement’s relative priority, and lets the team refine and clarify story items. But there are even more benefits that can be gained from the estimation process. Try to take advantage of these five opportunities for growth when your team is estimating stories.
The cost of delay for releasing a product can be due to many factors, but that value loss can seem like an abstract concept. Attaching hard numbers to a release timeline in the form of a time-value profile helps the development team and business stakeholders have a conversation about how long they have to build a product and when it would be best to enter a market.
The cloud and the rapid migration to mobile devices and the Internet of Things have made traditional software licensing schemes obsolete. Omkar describes new software monetization based on business, pricing models, and usage.
The iterative agile methodology provides a clearer vision, smaller time scale, and closer planning horizon. The authors look at approaches to estimation and planning, from product backlog grooming to task-estimating tables and more.
Cognitive scientists tell us that we are hardwired for deception, which makes accurate estimation almost impossible. We must simply accept that our estimates are best guesses and continually re-evaluate as we go, which is the agile approach to managing change.
When will you deliver that feature? How much will this project cost? Which features can I have in four weeks? These are all reasonable questions that both management and customers need answered, and traditionally, we’ve used estimates to provide such answers. But estimates can turn into commitments, dollars get spent based on misinformation, features end up misaligned with business needs, and all parties involved end up feeling misled and frustrated. The key question is, can we still make decisions without traditional estimates? Join us as our panel of experts discuss this question and many more. The panel will explore how teams can use #NoEstimates thinking to meet the needs of their stakeholders, how to maintain alignment without estimates, and pragmatic ways to move the focus from estimates to metrics and measures that enable teams to deliver high-quality products that will delight their customers.
Are you puzzled about why your estimate turned out wrong, or stressed from working to meet an impossible deadline? Some teams on inaccurately estimated projects suffer stress, burnout, and poor quality as pressure is applied to stick to an unrealistic schedule. Such project teams also descend into irrational decision-making—with potentially catastrophic consequences. Frustratingly, even when teams perform well, they are often judged by their failure to meet impossible deadlines. Andrew Brown will show how estimation errors are caused not just by new technology or intentionally manipulated estimations, but also from limitations in the way we think. Andrew will explain how cognitive biases contribute to estimation errors and show how to mitigate these biases. Learn how the planning fallacy, anchoring effect, and optimistic bias contribute to estimation errors and lead to irrational decision-making.
Isn’t it amazing? Stakeholders drop software on our desks and expect us to test it—without any requirements, design, or product knowledge whatsoever. About the only clear thing is the absurd and unrealistic deadline. We are expected to bend over backward, spread magic pixie dust, and heroically test quality into a product we have never heard of before. But testing in the dark is not impossible, and as Rob Sabourin shows, it can even be a very valuable and fun experience. Learn strategies to emerge from a murky fog into clear, meaningful quality insights and leverage unlikely sources about what stakeholders care about and what users really need the software to do. Rob introduces you to methods of reconnaissance-style, charter-driven, and session-based exploratory testing and help you provide meaningful estimates to stakeholders with minimal hard information about the software under test.