Scrum and agile are great methodologies for technology teams. Most other parts of large companies don’t have the time or the patience to define what they are asking technology teams to do.
How do you handle a sprint if you don’t have fully defined user stories with details or acceptance criteria ready? Do you post-pone the sprint by some period of time or are you supposed to make educated guesses?
Question by Sr Software Developer / Orem, Utah
Agile coaches answer:
Scrum and agile are no methodologies. ;)
You don’t need User Stories, the Scrum Guide doesn’t define what form a Product Backlog Item has to have. And a Sprint doesn’t have any preconditions regarding the Product Backlog Items to be implemented.
Since one Sprint follows the other you start the Sprint Planning with whatever you have. If the Product Backlog Items are not ready enough for the Development Team to be pulled into the Sprint, they have to either be refined or not pulled in the Sprint Planning.
Anyhow you will have plenty of topics for the Retrospective of that Sprint so that this doesn’t happen again.
Answer by Peter Götz
The short answer is that the team need to take the lead here to mitigate the issue (since business are too busy anyway).
If it’s important enough to develop, it’s important enough to have a discussion around – the risk and time going into accepting half-baked requirements will cost you more than it’s worth. Lacking requirements is often a sign that business actually don’t know exactly what they want or how to convert what they want to requirements (“I can tell you what I want if you ask questions but I can’t write it down”)
Set up the discussion with business – lacking requirements can actually be an excellent way of getting the conversation between business and tech going. Let go if demanding perfect requirements (the will never be anyway), but do demand a session to discuss them with business. The team need to take lead to convert the discussion to tangible requirements and better yet if they can recap with a mockup or something for business to “handshake” on.
Do set up some kind of definition-of-ready and communicate it with business – go for stuff like “we need to understand why and for whom”, “we need to agree on initial scope”, rather than “we need all edge cases documented by business”. Think you get my point J
If all this fails – communicate that you will move on with stuff further down the backlog until the conversation can take place and we understand what to do.
Never ever start sprints without a clear understanding of what – this fosters bad behavior which will be even more difficult to tackle later.
Answer by Tom Tingstadius