Written by South African Agile coaches Samantha Laing and Karen Greaves, “Coach’s Guide to Agile Requirements” is a book on how to teach the concepts of Agile requirements. It provides a complete plan to run a workshop where people can learn how to elicit, refine and organize requirements in an Agile way.
Estimates are part of our daily live. Every single day we ask and answer questions like: “when will it be done?”, “how much does it cost?” and use that “data” to plan the future of our projects. Some of us using rigorously formalised processes with heaps of Excel sheets, some applying more agile methods like planning poker. While doing that, we do not realise how estimates could be harmful!
Technical Debt is defined as the consequences of poor software architecture and software development within a codebase. Carrying too much technical debt reduce the ability of software to change and evolve. In this article, Jurgen De Smet explains how to manage technical debt from a business perspective.
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.
It’s all too common these days to see arguments on Twitter or mailing lists with these rules-bound zealots arguing that ”you’re not agile” because you aren’t following the rules to their satisfaction.
This talk is a study of a case in which three Scrum teams converged into a single large team Kanban system design. Working in separate teams resulted in issues with responsibility, hand-overs, resource utilization and a culture of blaming others. In a large, highly self-organized team the members could share responsibility for the whole, work on the right things and focus on flow.
Using Story points is a technique used by Scrum team to evaluate the relative size of user stories. If this technique works fine for single teams, it might be more problematic when multiple teams are involved. In this article, Paul Raymond explains why user story normalization is needed in contexts where multiple Scrum teams cooperate on the same user stories.
Scrum Expert Copyright © 2009-2026 Martinig & Associates