One of the common anti-patterns I see with new agile teams
is that they try and do the requirements
analysis in a linear fashion.
Something along the lines of PO -> Business BA-> Tech BA ->Architect
->Dev.
By the time it reaches the dev, it’s been several weeks and the
requirement is so far abstracted from the original intent that it’s incorrect.
This can be exacerbated with a team that may be under
pressure as they’ll default to previous waterfall behaviours and look to
deflect the pressure onto someone else.
In nearly every scenario where I’ve walked into a project
and they’ve told me they have an issue with the requirements and building
stories in time, I witness the above scenario.
Get a room. Grab a whiteboard. Have a chat.
Shane Hastie did a session at Agile Australia 2015 on
Product Ownership being a team sport which is a good read:
