What happens in Scrum without a Definition of Ready?
I have long advocated that Scrum Teams have a “Definition of Ready”; if you don’t have one, there are many potential negative consequences.
I have long advocated that Scrum Teams have a “Definition of Ready”; if you don’t have one, there are many potential negative consequences.
The Definition of Ready confirms the suitability of a User Story for development. If you want to produce quality increments, you need one!
A “Definition of Done” is a commitment to deliver a working increment meeting defined quality criteria to ensure the increment is complete.
Mystery stories? No points, no details, no naming conventions, technical tasks, ad hoc requests… Help! My Sprint Backlog is out of Control!
I can’t tell you how many times I have seen Scrum go wrong. If you want the perfect recipe for screwing up Scrum, you’re in the right place.
It’s a common misconception that there’s no planning in Agile (there is), and the Product Owner is responsible, but a lot can still go wrong.
In the fourth and final blog in this series on what happens when Agile requirements go wrong, I tackle the final four anti-patterns.
There are many ways requirements can go wrong in Agile. In Part 2 of 4, I tackle five more requirements anti-patterns so you can avoid them.
Unfortunately, quality is often skipped or overlooked when developing products using an Agile approach. So, who owns quality in Scrum?
So, can you add items to the Sprint Backlog during the Sprint? The Scrum Guide states that you can, but you may not want to do it. Learn why.