INVEST in Good Stories and SMART Tasks


Below are some XP tips for the Agile world...
The INVEST and SMART acronyms can remind teams of the good characteristics of stories and tasks.
User stories are requirements, consider them composed of the triple C:
  • Cards (their physical medium)
  • Conversation (the discussion surrounding them)
  • Confirmation (tests that verify them).

User stories act as a pidgin language, customers/users/programmers use it so that all sides can agree enough to work together effectively.

A good story is an INVEST story:

  • Independent
    • They don't overlap in concept, and can be implemented in any order.
    • Can't always achieve this; ex: "3 points for the first report, then 1 point for each of the others."
  • Negotiable
    • Is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. 
    • It captures the essence, not the details. 
    • Over time, the card may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories.
  • Valuable
    • ...to the customer! 
    • Developer concerns? frame them so the customer perceives them as important.
    • Splitting stories? slice vertically (ex: a full database layer has little value to the customer if there's no presentation layer).
    • Making each slice valuable to the customer, supports XP's pay-as-you-go attitude toward infrastructure.
  • Estimable
    • Just enough to help the customer rank and schedule the story's implementation.
    • Difficult if non-negotiated, as it's hard to estimate a story we don't understand. 
    • Bigger stories are harder to estimate
    • Estimates vary depending on team's experience.
  • Small
    • At most a few person-weeks worth of work.
    • Else it seems to be too hard to know what's in the story's scope. 
    • Therefore, smaller stories tend to get more accurate estimates.
    • Story descriptions can be small too, details can be elaborated through conversations with the customer.
  • Testable
    • An implicit promise: "I understand what I want well enough that I could write a test for it."
    • Characteristic of good requirements; writing tests early helps us know whether this goal is met.
    • Non-functional requirements? Figuring out how to test them will help team learn the true needs.
    • If a customer doesn't know how to test something, then story isn't clear enough, is not valuable to them, or they need help in testing.

For all these attributes, the feedback loop of proposing, estimating, and implementing stories will help teach the team what it needs to know.

An effective (sub)task is a SMART task:

  • Specific
    • Enough that everyone can understand what's involved in it.
    • Helps keep other tasks from overlapping.
    • And understand whether they add up to the full story.
  • Measurable
    • Key measure is, "can we mark it as done?" (definition of done :p)
    • Team needs to agree on what that means
    • Should include "does what it is intended to," "tests are included," and "the code has been refactored."
  • Achievable
    • Task owner should expect to be able to achieve a task.
    • They ask for help whenever needed to ensure they are up to the job.
  • Relevant
    • Should contribute to the story at hand.
    • Stories are broken into tasks for the benefit of developers
    • Customer should still be able to expect that every task can be explained and justified.
  • Time-boxed
    • Limited to a specific duration. 
    • Need not be a formal estimate in hours or days
    • Should be an expectation so people know when they should seek help.
    • If harder than expected, must split the task, change players, or do something to help the task (and story) get done.

CONCLUSION

  • As you discuss stories, write cards, and split stories, the INVEST acronym can help remind you of characteristics of good stories.
  • When creating a task plan, applying the SMART acronym can improve your tasks.


Comments

Post a Comment