Digging into the Agile Principle: What “Barely Sufficient” Means?

Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. Many organization are going through the agile shift from doing Agile to being agile, how do you dig through the twelve Agile principles and manage projects or even running business more effectively? For example, one of the Agile principles says: Agile requirements are barely sufficient, who decides what 'barely sufficient' means?
What is "barely sufficient"? "Barely sufficient" means to capture and record your requirements at just enough detail for the needs of those requirements for today's and tomorrow's. As with pretty much all other aspects of just about everything, the answer really is, "it depends." instead of asking who decides what barely sufficient is, ask what is a barely sufficient requirement. This is straightforward. A system behavioral related requirement is defined by its inputs and outputs. Definition of such essential for minimal yet quality requirements. If you're building something simple, where the code can be the documentation, then whatever the team decides is good enough to get to the design to inform the development. The team should decide whether the requirements have enough clarity to get the work done to an acceptable level, but it is not done in a box. Left to their own designs, developers often assume they understand more than they really do and end up building some really bad things.
There are a couple of perspective of “barely sufficient”: (1) It's best to do things just in time. And (2) It's best to adjust until what you're doing is just enough. Doing things just in time means they are done in time, but it also means that we know as much as we can know when we do them, and the opportunities for change between the time they are done and the time they are needed is minimized. So it would take some powerful arguments to override those motives. Doing just enough is minimizing waste. Doing any more would be waste. There are people who argue that it is better to do 'not quite enough' on the grounds that good feedback loops will tell you, in time, that you need more and at that point you can do more. However by the time you find you've done too much it's too late to do less. So feedback loop is important. You get feedback that tells you when you haven't done enough; if you're careful you get feedback telling you when you've done too much. From this, you get better next time at doing 'just enough' - or 'not quite enough' - depending on which you are aiming for.
Simplicity--the art of maximizing the amount of work not done--is essential: It means that every team should find that sweet spot where they do the least amount of work to fully get what the requirement is. This will differ greatly from team to team because of factors of domain knowledge of both team and product owner, experience of team, effectiveness of the team, agile maturity and likely more. The challenge with agile requirements is when you need more than the code or transient user stories in order to manage your system capabilities for the long-term. There needs to be a boundary around the requirements with a well defined acceptance criteria. A good story has the following attributes: (1) Independent (2) Negotiable (3) Verifiable (4) Estimable (5) Small (6) Testable
Principles are those core decisions values, not value as in benefit, but values as in beliefs that shape behavior and define culture. All Agile principles help build the culture of change with three “I” - Interaction, Iteration and Improvement.







Follow us at: @Pearl_Zhu