The short answer: Yes and No.
The traditional approach, where you create detailed requirements and specification documents early in the project’s life-cycle often leads to an increased overall project risk and may result in significant wastage in practice. This is due to the fact, that people have difficulties to clearly define their requirements early on.
In contrast, agile development works with user stories, which are basically short, easy to understand description of a feature from the business user perspective indicating:
- Who wants
- What and
- Why
So a user story may look like this:
“As the president, I want to be able to click on a red button to immediately order a diet coke, so that my thirst for sweet beverages can be quenched without gaining any weight”
All user stories are then gathered in the product backlog and the project is good to go. Easy, right?
This premise sure sounds tempting, as nobody likes the long and tedious specification work, which is common in waterfall models (traditional approach). After all, it is much more interesting to get into the development phase right away and see first results just after a few weeks.
But is this kind of specification enough?
A Scrum team normally consists of a scrum master, a product owner and the development team. Even though the development team is considered to be an interdisciplinary team -whereas every member is responsible for the development, testing, architecture, operations and business analysis - the development team more often than not consists of programmers and application developers.
In a simple project, this might be enough, as the development team simply sits together with the product owner or business users in so-called grooming sessions, in order to discuss a user story in more detail until all aspects are clear. In more complex projects, however, a more detailed specification of these user stories needs to be prepared in advance of any given sprint. As sprints are usually between 2 and 4 weeks, this means very little time for the specification.
In this case, a dedicated specification team must race ahead of the development team in order to prepare enough user stories, so that the development team does not run out of features to implement. Such a Just-In-Time specification is only possible if the specification team is well versed in the subject matter and agile methodologies, closely synced and connected within the organization and fully committed to the project.
After all, the agile methodology isn’t called agile for no reason. While the agile approach may reduce the lead time on specification significantly, the necessary effort can’t be reduced to the same extent. It's like running a marathon at sprint speed: You might get there faster if you don't die of a heart attack first.
I worked in many agile environments and the right solution to specification is highly dependent on the project and the client, but I'm curious to hear from your experiences with agile specification.
