User Stories

Programming for Data Science

What are User Stories?

User Stories are at the heart of Agile development.

Instead of eliciting requirements through a formal process, teams ask clients to give their wishes in verbal form:

  • As a [type of user]
  • I want [an action or behavior]
  • so that [a benefit/value]

Note that in this context “users” may be any stakeholder, including developers, not just “end users.”

Process

These “stories” are written on index cards.

They are developed in the context of a conversation between developers and clients to clarify the meaning of the sentences.

These are then converted by the development team into formal requirements.

Requirements

Recall that requirements are the building blocks of a software design specification (a “spec”).

Having a clear spec allows developers to design and test code effectively.

There are two main kinds of requirement:

Functional – relating specifically to how the software will work, i.e. function.

Non-functional (so-called) – relating to the broader purpose and context of usage.

Each requirement relates to a feature of the product.

Priorities

Once a list of requirements is developed, they are then prioritized.

One technique of priortization is called MSCW, pronounced “Moscow,” which stands for:

  • Must Have: The product absolutely requires this functionality. The feature is critical to the app’s success.

  • Should Have: It would be great if product had this functionality, but it isn’t absolutely required. These may be important but not as time-critical as Must-Haves.

  • Could Have: The feature is value and is desirable but not necessary for the product to perform its primary tasks.

  • Won’t Have: The feature is non-critical or low value. It may be out of scope of the products purpose.

By comparing each requirement with a scope definition in a project charter (not discussed here), requirements are assigned on of M, C, S, and W.

Very often, only the Ms are kept for the first version of the product.

Milestones

After requirements have been prioritized, they are grouped into milestones.

Milestones are time units that follow a sequence. For example, a database-driven web application might have these:

  • Stand up the development infrastructure.
  • Establish the data model and back-end architecture.
  • Build a minimally viable product.

Milestones may or may not be tied to a specific date, but they do follow each other in time.

Scrums

In executing the project plan, the development team meets regularly in brief stand-up meetings called scrums.

These may be held daily but they are meant to be short and may adjourn quickly if there are not pressing issues to discuss.

Stakeholder representatives, such as the product manager, may attend too on occasion.

Clients

At regular intervals, clients are introduced to the process

Prototypes, MVPs, etc. are presented.

Feedback is elicited early and often.

Communication

The whole process is driven by a communication plan that defines such things as:

  • Frequency of meeting.
  • Mode of communication – F2F, Slack, Git.
  • Task management tools – Jira, Trello, Smartsheet, etc.

Other Artifacts

Other artifacts are involved in this process:

  • The project charter.
  • The project plan.
  • A Kan Ban board.