If you’re using Scrum in your organisation to develop software, then you are very well aware of the challenges of getting your Stories spot on. Writing a good User Story is not easy; it depends on both business and development factors.
The ideal Scrum Sprint planning is fast, the estimation session does not drag on, however usually the reality is nothing like that and both the Product owner and the development team are equally to blame.
Many questions raised for each User Story; unclear acceptance criteria; missing artefacts, unresolved cross-team dependencies, unresolved 3rd party dependencies... The problems are far more apparent when the Continue reading
If you’re using Scrum in your organisation to develop software, then you are very well aware of the challenges of getting your Stories spot on. Writing a good User Story is not easy; it depends on both business and development factors.
The ideal Scrum Sprint planning is fast, the estimation session does not drag on, however usually the reality is nothing like that and both the Product owner and the development team are equally to blame.
Many questions raised for each User Story; unclear acceptance criteria; missing artefacts, unresolved cross-team dependencies, unresolved 3rd party dependencies... The problems are far more apparent when the Continue reading
