Category Archives: Agile software

The 3 Cs of User Stories

In our consulting work we often refer to the three C’s of user stories, here is what we mean.  The C’s are abbreviations for the:

  • Card
  • Conversation
  • Confirmation

The card contains little information and is often written in the form “As A <<Role Name>> I want <<a feature>> so that <<some value delivered>>”.  There are many different forms that this can take, but what is most important is that what is written, is meaningful to the team delivering the feature and the customer (or product owner) requesting it. Developers cannot write software from the card alone and to that end they need the next part … the conversation.

The conversation is the essence of the requirement and conversations can spawn many outputs or artefacts such as models, notes, story maps or even good old fashioned code!  I like to think of the conversation as the most important part of the story because this is where the learning is achieved.

For years as a systems or business analyst I used to write requirements specifications that could sink a small boat and then lob these over the partition to my design colleagues (god I hated conversations with designers – they asked way too many questions ;0) ).  But seriously, minimising the written word to specify requirements is important, but you maybe can’t get away with eliminating it altogether.

Conversations, and more importantly evolving conversations, allow the developer/designer to hold the concepts of the requirement in their head while the design and code become the output of a requirements conversation rather than some weighty tome.  This minimises ambiguity and uncertainty as the analyst, or better yet customer, can see their thoughts become manifest as a result of a few insightful conversations.  Changes can then be made directly as the feedback is received rather than going through some lengthy change management process which will result in a document being changed giving the risk of more ambiguity.

The confirmation (often written on the back of the story card) gives us the high-level criteria against which the resulting feature will be tested against.  I like the idea of specifying the system by examples of what the system will do both when it functions correctly or incorrectly.  This is a better way of creating a specification as opposed to my boat sinking documentation of yore. Alternatively simple closed questions such as “does the screen go black?” may well suffice for acceptance criteria.  But these in themselves will not be the complete set of acceptance tests but only a high level set of tests to give the customer or product owner confidence that the feature that has been created fulfils their criteria of a working feature.

The 12 Agile Principles for Software Development

Here is a reminder of the 12 Agile principles for software development.  These have been recreated here for your convenience.  It you would like to go straight to the origin of these principles then please click here.  And yes I have corrected the americanised spelling 🙂

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.