When your Agile Requirements go Wrong, Part 4
In the fourth and final blog in this series on what happens when Agile requirements go wrong, I tackle the final four anti-patterns.
Business Analysis is the practice of eliciting stakeholder needs, analyzing and modeling their requirements, and providing solution options and recommendations.
In the fourth and final blog in this series on what happens when Agile requirements go wrong, I tackle the final four anti-patterns.
The problem of Agile requirements going wrong is endemic; this is the third of a four-part series on what can go wrong, and how to fix it.
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.
The problem of Agile requirements going wrong is endemic; this is the first of a four-part series on what can go wrong, and how to fix it.
Some people can jump right into the Product Owner role, but for most, training provides an essential foundation to do the job successfully.
In Agile, defects can be handled in different ways – so what should you do when you discover a bug? Find out how to handle defects in Agile.
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.
There are many ways to document Acceptance Criteria for your user stories. But what’s the best way? Check out some different methods.
Is there is a “right” way to write User Stories? It sounds simple, but like Agile, User Stories are easy to learn but difficult to master.
It’s a known fact that poor requirements can cause projects to fail. When using Agile, these problems can be even worse. Learn what to avoid.