Agile software development methods have reached great popularity among technology-based companies around the globe, arguably due to their effectiveness at managing the project stakeholders’ expectations and goals. However, this positive outcome is directly related to the team members’ ability to carry out the planning phases. And unfortunately the minimalistic theory frequently observed in agile processes tends to result in poorly written user stories.
Agile methods are often described as “common sense”. For this reason Ken Schwaber refuses being titled the Co-Creator of Scrum. Several software development practitioners such as Ivar Jacobson, Grady Booch, and James Rumbaugh all contributed to the set of principles that today form the Scrum framework.
However, having Scrum, XP, or any other method classified as common sense leaves a lot of room for interpretation by the individuals applying them. Thus, iteration planning efforts sometimes end up being superficial, not entirely committed to the system actors’ real goals. As a practical consequence, user stories are found reduced to single sentences hanging on the white-board.
It is clear that User Stories are not Use Cases or Requirement Statements, as detailed by Mike Cohn, and highlighted as follows. Firstly, use cases are generally written as the result of a long analysis, whereas user stories are written as notes that will be used to initiate further analysis conversations. Secondly, requirement statements make costs visible only when all of them have been formally written in a lengthy document, whereas with user stories a complexity estimate is associated with each story immediately. Costs are then easily calculated by taking into account the velocity of the team.
Nonetheless, developers should not underestimate the complexity inherent in each story, and complementary theory can be found on this topic. Ron Jeffries breaks down the stories into three aspects: Card, Conversation, and Confirmation.
Firstly, the card does not detail the story in depth, but successfully identifies it. Typically, team members and product owners adhere to the following template, popularized by Mike Cohn: “As an <actor>, I want to <action>, so that <achievement>”. Although advantages derived from using this template have been listed, other agile evangelists have proposed enhancements. Elizabeth Keogh, for instance, came up with a new user story format that better emphasizes business value. One way or the other, templating has been the common approach, and teams should adopt one that will fit in smoothly within their environment.
Secondly, conversation is the activity that communicates the requirement from customers to developers during the product and sprint planning. At this stage, details such as dependencies and barriers are mapped out. As depicted by Jeffries, the conversation is largely verbal, but is often supplemented with documents. It is important to bear in mind that good communication is a key success factor in any software development project, and none of the artifacts produced throughout the process may substitute that.
Finally, stories are verified through confirmation or, more specifically, acceptance testing. All criteria taking into consideration ought to be defined during planning phases as well.
Although the theory presented above brings some structure to the loose perception of user stories, the writing itself remains vague. So William Wake advocates that agile practitioners should INVEST in good stories and SMART tasks. Despite not being a particular fan of forced acronyms, I have to admit that some guideline will be welcome here.
Briefly, characteristics that form a good story description are the following:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
.
Hence, a story should be independent from others, negotiable between customers and programmers, valuable to customers, estimable in terms of complexity, small for the sake of understandability, and testable on account of readiness confirmation. Further studies suggest that “Small” should be replaced with “Sized appropriately”, as the bottom of the product backlog may contain items that are not fully understandable by the team yet, also known as Epics.
Tasks, in their turn, should be:
- Specific
- Measurable
- Achievable
- Relevant
- Time-boxed
.
So a task needs to be specific by addressing one particular point, measurable in order to be tested against the definition of done, achievable by the task owner, relevant to the story at hand, and time-boxed. This latter characteristic should not be perceived as a formal estimation in hours or days though, as it does not work. The raw material in Software Engineering is the developer’s own intellect, and nobody would be able to estimate its maturation time. The same applies to activities such as painting or novel writing. Civil Engineering, on the other hand, benefits from using raw materials that allow for accurate calculations, such as concrete and iron.
As a final note, during the planning, instead of defining longer iterations and allowing for bigger stories, you might be interested in giving the following set of constraints a try. SWAT has successfully built some of its software by adhering to them. Manageability goes through the roof!
- 5-day sprints
- 5-point stories, or less
- 2-developer teams, up to 4
.
In conclusion, a better organized agile planning is more likely to drive the team towards the goals identified by project stakeholders. Theories and guidelines have been proposed, and I suggest bringing these concepts to the table when starting a new agile project.
Related Posts
