One of the best practices of Agile/Lean development is just enough, just in time specifications. But this is often times misunderstood by teams and harder to align by business.
So what is a specification anyway? It’s a software feature required to meet the vision of the product. It talks about what but not how. It talks about the experience by customer rather than a database table or a technical framework.
Then, what is just enough, just in time specification? Well, let’s look at this case. If there is a steel manufacturing plant, how much raw material (inventory) should the plant hold? Should it be sufficient for next one year or for next few weeks? Of course it’s for few weeks, but with the expectation of continues supply of raw material. Before the raw material turns to steel, it goes through various stages, for heck of it, let’s say, when it’s in the earth’s ore, its 0.5% refined, after 1st treatment of the ore, its 25% refined and so on and so forth till it becomes a state when furnace can spit of the desired quality steel.
Even product backlog should be treated as inventory. It has ideas, concepts and specifications which are refined at various levels.
Now, the problem is when PO comes up with a new requirement during planning meeting for the upcoming sprint, he/she and the team should be aware how refined the requirement is. If you see all items directly end up in “Fine Grained” state, then you know it’s not evolving. This usually results in lot of readdressing existing which could have been easily avoided.
To sum it up, Just enough, just in time specifications should be part of an evolutionary process and will work of both team and business understands the level of granularity of the requirements.
