As a management and collaboration tool, ScrumDo uses the "work card" as the most fundamental container of work.  While work cards may often be the same thing as a User Story, this is not universally the case.  Let's take a deeper look.

What's a User Story?

User Story is a term of art that comes to us from Agile frameworks (its orgins lie in a software development framework called Extreme Programming).  A User Story is intended to represents a single capability (or piece of functionality) that can be produced in a relatively short amount of time and will represent usable value once completed. It is intended to be written in easy-to-read, non-technical language that describes what is intended to be produced from a "business" outcome perspective. In the software development realm, User Stories are typically constructed in the following format:

                As a (role / persona) I want to be able to (perform some function)
                so that I can (business purpose).

Often times, when a particular business objective is being planned, the work that would need to be undertaken is initially described in terms of very large, high-level capabilities.  We can create work cards that describe these large chunks of work, but such a description would not necessarily help us figure out what discrete things need to be done to complete that work.  These high-level descriptions are still relevant to planning and coordinating activities at a strategic or program level, but they aren't particularly helpful to understanding and managing things where the rubber meets the road.  In Lean-Agile frameworks, we emphasize breaking down work until it's at a User Story level.  

From a management perspective, it's therefore critical that the tools we're using to manage our work allow us to establish and visualize relationships among the various cards that make up our portfolio of work. ScrumDo allows users to do this by creating multiple parent-child relationships (a tool feature we have traditionally called "Epics" and are transitioning to call "Collections").

Good User Stories

Regardless of the nature of the work you're seeking to manage in ScrumDo, we can benefit from the best practices that have emerged from Lean-Agile practitioners in the software development space. Here's a handy acronym that helps us remember the characteristics that make for a good User Story:

  • I – Independent. We want to be able to move stories around, taking into account their relative priority. This means stories are easiest to work with when they are not dependent upon other work or other delivery teams.
  • N – Negotiable. Stories are not an explicit commitment to produce certain features, but a framework for ultimately defining what to produce for the end user.  Therefore, good User Stories allow us to negotiate an appropriate deliverable to which the delivery team can confidently commit and is enough to satisfy key needs.
  • V – Valuable. A story needs to be valuable to the end user. Development issues should be framed in a way that illustrate why the end user would perceive them as important.
  • E – Estimable. We want stories to be estimable, otherwise they're never likely to be tasked for delivery. Whether or not a story is estimable is a function of being negotiable (you can't estimate what you don't understand), of size (bigger stories are harder to estimate), and of team experience.
  • S – Small. Stories should be small -- no more than a few person-days of work. Above this size it's almost impossible to know a story's full scope.
  • T – Testable. Finally, we want stories to be testable. If a story isn't testable, you can't really determine when it's done. In the software development realm, Test Driven Development has shown us how actually writing the tests early helps us know whether the business goal is met.

A Quick Take on Time Estimates

Though the topic of time estimation is beyond the scope of this article, we do want to say it is rarely the most critical element of reliable forecasting.  That said, because it is a variable many teams and organizations heavily rely upon, we support it in a number of ways within ScrumDo.  

First, each work card you create will contain an has an hours:minutes field that can be filled out during creation or subsequent editing. Your time entry in this area is intended to represent your overall time estimate for the work described in that card.

If the Card is not an Epic (Parent) card (in other words, at the User Story level), then it may subsequently be populated with sub-tasks associated with the work described in the card.  Task cards also contain a field for time estimates.  Note, however, that if you choose to enter time estimates for your tasks, ScrumDo will treat these as elements of additional time that's needed to complete the User Story. So if you enter 1 hour for a story, and 1 hours for a task within the story, that’s telling ScrumDo you expect all that work to take two hours.

Did this answer your question?