At the end of every sprint, the team demonstrates the work they’ve completed–the inspect and adapt cycle for the product. Then, the team holds a retrospective so they can inspect and adapt their methods, engineering practices, or teamwork. When I talk to some teams, though, its clear they aren’t getting much benefit from their retrospectives. We’re all too busy to spend time in a meeting that doesn’t accomplish anything–so I can’t blame teams who want to drop their do-nothing retrospectives. If you aren’t realizing the benefits of retrospectives, try the approach described in this article.

Scrum is not a silver bullet, it’s a silver mirror, showing you what’s happening in your organization.

Traditional project planning techniques rely on a comprehensive, detailed, and stable requirements specification as a prerequisite for creating a project plan. This approach is not only error-prone when dealing with innovative and complex products, it is also difficult to employ in an agile context because not all requirements are known upfront and changing requirements are welcomed, rather than treated as an unwanted exception. This article describes an alternative project planning approach that flexes requirements but fixes time.

Agile requirements can take many forms, from user stories to use cases and beyond. Read how one team experimented with requirements development approaches and found several methods that work for them.

Product backlog items can take many forms. I prefer user stories. This article explains why.