Hi:
Has anyone defined what "just good enough" requirements look like on an agile project? Of course, many needs will vary according to situations, but are there not essentials in requirements documentation?
Tony
Hi Tony,
Great question! On the agile projects I've been on the answer varies depending on several factors such as:
In the ideal agile case (i.e. most of the assumptions that go into an Agile environment are met), we've started off with initial requirements that are simple user stories lasting no more than 2 short sentences (typically just 1 sentence). This is enough to get the developers talking to the users to figure out what is really need but provides a good scope for the project.
In other cases our 'good enough' was a fairly comprehensive requirements doc that would give the developers a starting point to develop, but did not necessarily have all the little details finalized. Our requirements were services-based as we were developing an SOA solution for system to system integration. Whenever they had questions they could come to the BA team for clarification, which typically meant we would be refining what we had already documented to get it to a point that there was clairty. If we needed to we would go back to our business people to get clarification.
So I think you need to assess your team and figure out what is good enough for you. The goal is to maximize the efficiency of the team so developers aren't waiting for information and you aren't running around all the time looking for clarifications while at the same time not spending so much time up front on details that can and likely will change.
larimar:
Thanks for the response. In data flow diagramming, the "just good enough" has been clearly and concisely identified. It is called an essential data flow diagram (i.e., a data flow diagram that just shows the essentials). We may not be able to obtain the essential because of limits to users, but we know what is essential - and what it is for any project. It seems strange to me that in the agile world the essential (the "just good enough") is such a vaugue, it-all-depends, touchy-feely thing?
I guess the "just good enough" requirements mean just good enough for a certain group of people, ex. BA team. After they are handed over, somebody else (ex. programmers) still need to continue, talk to end users directly, get all details done and finalize. The good thing about this is the early involement of technical people. Instead of programmers to finish up with detail requirements, I think BSAs should be better people for it, who maybe in BA team or development team.
Irene
Irene:
What I hearyou saying is that there are no firm essentials - that the essentials are situation dependent. (Kind of sounds like a debate on reliigion don't it?)
Sooo, my current understanding of agile is: Nothing firm, it all depends - but don't waste time.
I despute this premise: Max efficiency and effectiveness is only obtained by a focus on the unwavering essentials. (Now it really sounds like religion!)
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: