I have been at Wikipedia again. This time at the User Story page.  I didn't like the contents as usual, and this time I drafted a variation on the Wikipedia page and published it in the Business Analysts Handbook. A copy is recreated below for your interest.  It also serves well as a first post in the Agile Thursdays series.


Introduction

A User Story is a marker indicating a request for work to be done.

User Stories are often conflated with software or business requirementsbecasue on first impressions they look like requirements. They are actually independent things.

User Stories were first introduced to the world by the XP community in the late 1990s, although the concept of stories and narratives being effective tools for communicating requirements daes back at least into the early 1980s.

Important things to consider about User Stories 

• They are a token for doing a piece of work and are not a software requirement in the traditional sense 
• They are a 'trigger for a conversation ' and build upon the Agile Manifesto principle that face to face conversations are the most effective form of communicating ideas 
• A User Story is likely to evolve over time as people's knowledge on the topics area matures 
• Generally, when a software team starts work on a User Story a clear 'definition of done ' should be available 
• User Stories are ideally written on index cards or similar because of the value of visualizing the workflow , keeping them simple and osmotic communication . 

Card Conversation, Confirmation
The three essential elements of a User Story are the card, conversation and confirmation.

These are described below under the following headings.

• Card = Physical v Electronic 
• Conversation = As a Product Owner I want a template 
• Confirmation = Start with the end in mind 

Physical v Electronic
User Stories are typically written on index cards or post it notes because of the value of osmotic communications, the lightweight nature of the tool and because face to face communication is optimal for project team communications.

Many teams also capture User Stories in electronic media such as requirements management or test tools.

There are many purpose build product backlog management tools on the market.


As a product owner I want a template so that it's easy
Since the mid 2000's a 'common form' of User Story has become dominant. It is presented in the following form;

• As a [user type] 
• I want [an interaction+outcome] 
• So that [I get some form of value] 

The benefits of this templated form are real and tangible. An important part of both requirements management and workflow management is effective partitioning or dividing of the model elements into smaller parts. Diving the stories by the user type is a useful technique. Occasionally a feature or service will be identical for multiple users but more often than not there are differences, subtle or obvious, that the division helps surface.

The "I want" element generally describes some tangible interaction or feature. Because of this element a User Story is often conflated with a Use Case, a scenario or a feature. And it may well describe any of these or other thing.

Again partitioning is relevant and important here. But the main driver in this space is to partition the work into a small, independent pieces of work. (See the INVEST mnemonic.)

Software developers usually have a lot to offer in relation to requirements and how they should best be fulfilled. Often they have been constrained by a lack of awareness of the motivation for the requirement. It's also a common client failing to jump to solutions to early. Asking for the motivation in terms of business value helps everyone focus on what's most important in the story. SO explain why in the "So that" clause.

But the template has it's detractors.
By proving a tamplate in the first place you provide a platform for people to communicate in written form with the idea that the communication is sufficient and complete.

Unlike requirements a User Story is not a complete brief. It is aimed at being a trigger for a conversation and is purposefully incomplete so that the conversations can be had to further elaborate understanding collaboratively.

Start with the end in mind
A clear definition of done is important for User Stories as they re work requests. By being clear about 'done' teams are better able to determine when they have not yet met the minimum quality and capability thresholds, and when they have gone too far.

Typically the definition of done is created via a test case or acceptance criteria prior to commencing work on the user story. Early User Story advoctes simply used the trigger "This will be done when..." to stimulate the discussion on 'done. More recently the idea has been elaborated. From the same vector as the "As A, I want, So that" template comes Behaviour Driven Development (BDD.)

BDD is more than just a form for acceptance criteria. It is also a framework for managing stories and requirements more broadly. But it has also been adopted as teh dominant form for acceptance criteria on User Stories with the template;

• Given 
• When 
• Then 

Where given describes a starting state, when describes a trigger or catalyst and then describes the new state of being. This template form suffers the same strengths and weaknesses as the "As a I want" template.
Further reading

• Mike Cohn's User Stories Explained 
• Wikipedia on User Stories 
• c2.com on User Stories 
• ExtremeProgramming.org on User Stories 
• Scott Ambler on User Stories 
• User Story Template 

Related topics

• INVEST - A quality checklist for User Stories 
• Kanban - another concept for work tokens 
• Story Maps - a way of managing large numbers of stories 
• Behaviour Driven Development - Test thinking applied to stories
• Stories as Inventory - understanding the cost of too many stories (or requirements)

I thought I might try something different with my blogging: A structured approach.

In the early days of this blog I was exploring and discovering techniques and models from the engineering paradigm of project management and requirements.  I learned a great deal of useful stuff, some of which is re-emerging now as part of the Kanban movement.  Given there is so much interest out there in the agile thing I thought I might try a regularly and specifically themed agile blog.

I'll be drawing the post topics from the local Agile meetup groups.  Their goal will not be to give definitive answers on topics, but to raise awareness and to provide a platform for further investigations.  I hope they are useful.

If you want to see a summary of all the topics covered to date try searching the blog for "Agile Thursdays."  

Check lists beat templates hand down.  Checklists say "Have you done enough?"  They help you think through the issues.

And they can become mindless activities as well.  Checking the box unthinkingly, or adding new items to the checklist without ever taking the time to trim some unnecessary items.

But I reckon they are still better than templates. They are definitely more lightweight.

I just created a checklist to help someone with little project experience think through their project needs.  Take a look. I'd appreciate some feedback.

• End to end analysis framework

It's not perfect.  It's not even complete, I'd say.  But how would it stand up as a newbie guide?

You're in the weekly project status update meeting. The agenda has been reviewed. Last week's minutes are quickly discussed. The PM asks for any new business and finally its time to do that last task we all dread...
Review the project schedule.
The PM opens up MS Project, filters by task end date and asks everyone in the room for a status of the tasks that will end during the next week. Its a painful process, takes at least half of the meeting and most everyone is checking email while their colleagues provide updates.
After all the updates are added to the schedule, the PM asks Project to calculate a new end date, only to find that the project just slipped two weeks.
Oops.
Now the PM goes into panic mode. How did this happen? We were ahead of schedule last week and now we're going to be late! Where is the slack time? Who is on the critical path? Can we crash this thing back to baseline?
The sky is falling!!!!
Or is it?
This situation has always bothered me in ways that I never really could put my finger on, but this week I think I finally understood why this bothers me so much. While on my commute, I was listening to the Back to Work podcast, featuring Merlin Mann and Dan Benjamin, and the topic focused on projects and slipping dates. Merlin's main points were not directly related to my epiphany, but it did get me to thinking some about the whole concept.
Here's the deal... I don't believe dates ever slip, no matter what happens in the project plan. Dates are fixed, and not just because some executives says so. The day a project is over, with whatever system or process changes implemented, is the day it was done. It doesn't matter if that day was weeks early or years late, that is the day the project finished. You can't go back and change that date and since it is now live, you can't go forward in time and make it go live again (at least not with that particular phase).
End dates are always fixed, but what isn't fixed is our understanding of that date. Its possible, maybe in probable, that at some point during the project, something will come up which alters our perceptions of the project and how close we believe we are to its end.
The end date did not change, only our ability to accurately see that end date.
Big deal, you say, the effect is the same. That is true, but I believe that understanding end dates in this way changes our perception of projects in general.
If dates 'slip', this is seen as a bad thing; like we're not doing our jobs or that something unforeseen has impacted the schedule in a way that is not easily recoverable.
If my view is correct, then new information has been assimilated and we now have a more accurate picture of reality.
I don't know about you, but I think my viewpoint feels a lot better.

This sat in draft for a while.  It's about bureaucracy, PMOs and change.
Some quick questions to get you involved;

• Do you know the people in your PMO?
• Do they know you?
• Are they committed to seeing your project succeed?
• Really?
• Or are they just about process compliance and weekly status reports?

Some PMOs are really useful, some are less so.

(PMOs are a nebulous thing, so I might run up another post on my views on what makes a good PMO at another time.)

I recall once I had to go into a meeting where I had to justify why I wanted to create addional project documents, and why I wanted to vary from the usual tempaltes.

The reason I wanted to do 'extra' documentation is becasue we want to demonstrate new processes and methods for the organisation, and as a result want to keep them comfortable while w experiment with their people and processes.

We'll follow good agile practices and do fortnightly product reviews, and product burn up charts, and we'll also provide a report showing time and money spent against a target.  We'll work with a backlog full of user stories, and we'll also provide a high level requirements summary for our main release phases, one at a time, focused on the next release.

We definitely want to present a Project Management Plan, and a Quality Plan and Communications & (people) Change Management Plan which aim at explaining our methods and thinking through some of the more complicated parts of the program.

So, if I want to go above and beyond in terms of project documentation why the hassle?

Well, for one thing I also want to omit redundant documentation. In particular some of the requirements documentation.  We already have plenty of detail to hand, so why both rolling it up into multiple summaries and decompositions?  We already have a product vision statement and release roadmap so why elaborate that into additional documents that are at the heart of many project failure modes.

And while I am on the topic of reducing overhead, I would really like to abandon the template approach to documentation.  I get the point of templates, and in the past templates have helped me learn, but checklists are a much more effective tool than templates and make for less overhead

I specifically want to abandon the parts of templates that repeat the same shot over and over again so the repetitive and incidental details can be cleared out of the way, and so that important information can be added. Remember white space?  I want a crisper and clearer message.  I want the readers to engage with the content.

Picture of the PMO manual care of Celeste CC @ Flickr

You've heard the phrase "All models are wrong: Some are useful," by George Box, a chemist who taught himself to be a statistician.  My takeaway from this is that all models - and that is everything written down in all management texts and training manuals everywhere - is that the model is a lens to look at a problem through.

When I was an undergraduate at university studying marketing we were discussing the Marketing Mix.  "When launching or developing a product..." the lecturer said, "pay attention to Price, Promotion, Product and Place..."

I sat there thinking.  I didn't have corporate experience and this didn't make sense.  It just seemed to simple and to pat. (Four Ps!)  I was trying to learn this stuff by applying it to the bar and restaurant jobs I had.

How can I apply the four Ps to the restaurant?  We can't move it, especially me as a waiter, so the distribution aspect is a moot point.  Maybe we can change the prices and the menu (product) and sure we could do something to raise the bar when it came to promotion.  But what about the other aspects - the relationships the staff had with each other, the way we interacted with the customers, the suppliers (especially the alcohol sales reps!)

So I said as much to my lecturer; "This doesn't seem to be enough.  Surely you need to think through more than this to launch and manage products."

It was then I got one of the best nuggets of information from that degree.

"It's just a checklist to help you along.  It doesn't give you all the answers.  You have to use your brain to solve complex problems."

I wonder how he remembers the conversation, if at all.

Back in June of last year, I wrote a post entitled A new Facebook Use Case where I suggested that what FB really needed was a translation utility for comments. Called it.

One of the members of my QA team recently said something about me that made me smile. It wasn't that the comment was some kind of over the top suck-up or a snarky jab, but something that was a subtle reminder, in the midst of a sentence on an only vaguely related topic, of why I get up and go to work every day.

He said I was the only person he knew who loved their job.

The sad part is, I don't think he's far from wrong. I do work with several people who I know do love their jobs and it is clear from my daily interaction with them that their passion for what they do comes through in every conversation, every email and every line of code.

Its people like this, those who think of what they do as craft, who inspire me. I'm lucky; in my current job, I'm fortunate to have many of them who work with me. In my career, I've worked with people who are all over the spectrum when it comes to intelligence, motivation, perception, knowledge, wisdom and taste, but rare has been the person who really has a passion for what they do.

Passion is fleeting, but when it is really intense, its something that has you and not the other way around. Its something that I don't think you can fake; its either present in what you're doing or its not. The quality and the responsiveness of your work is directly correlated to exactly how passionate you are about it.

Even though I crossed the line years ago from individual contributor to manager, I still make it a point to regularly go back and do some business analysis work just to keep my skills sharp. Strangely enough, every time I sit down to do a bit of light analysis on a project, I can't help but remembering why I love this kind of work so much, why it fits me so much. Simply put, I get to make a difference for someone (or as I am fortunate enough to do, for millions of someones).

Given that passion, it probably shouldn't be a surprise to any of you that I obsess about projects. There isn't a better way to illustrate this than to realize that for two years (minus the last 4 months), I've been regularly writing on this blog. That isn't easy, especially with a crazy workload, long commute, a 2 year old and a small bit of socializing. Obsession over this topic is something that drives me, not the other way around.

Obsession is a powerful thing that John Gruber and Merlin Mann nailed. Listen to the audio in the link on this page as these are two guys who really understand what it means to take obsession and give it voice. Their obsessions are different, albeit related, to mine and I strive to have a voice that is as strong as theirs. In particular, pay attention to Merlin's discussion of writing about Jawas. Brilliance.

One of the things writing on this blog has helped me with is to find my voice. The last couple years have helped me refine what I really feel is important in a project and the direction I think projects will take in the coming decades. Technology, especially in the mobile space, stands to make a radical shift in how we elicit, document and analyze requirements.

The biggest change, in my mind, will be using video in the requirements process, especially agile processes. We can already do this today, but mostly its done by making some kind of prototype or slide deck, narrating over top of it and letting your remote users get a feel for what it will be like to use some kind of application. Pulling all that together into a produced video takes lots of time and planning. I don't think this will be how we do it in 20 years.

I see our business users watching someone failing at a process, pulling out their pocket communication devices (we better not be calling them phones then!), snagging a video of the incident, tagging spots in the frame, adding some text or commentary on top of the video, emailing it to the project team and waiting a few hours (better yet, minutes!) for the adjustment to the system to be made.

Or how about the stakeholder using that pocket communication device to make the adjustment themselves! Instead of creating only the tool used by the person performing the process, why not create the next great app that is used to create the next next great app?!?

Its ideas like this that really get me excited. My obsession is going full speed and my voice is coming along. I hope you all can say the same.

I have been over editing Wikipedia again.  This time on Functional Requirements.

Yes, it's the poor quality that revolves around the Requirements and analysis topic that drew me in.  Wikipedia's content in this space is a classic example of the plumber with leaky pipes syndrome.  Each time I see it I just can't help myself.  I have to edit.

But this time I am stuck.

My question for you dear reader is this;

Where does the idea of the Functional Requirement (as opposed to just a plain ol regular requirement) come from?  What is the origin story of this mystical term?

And while I am here, can you share your view on what the essential elements are that make a requirement "functional?"

Thanks in advance,
Craig

Stakeholder analysis tends to be an underdone activity in most projects.  There seem to be a number of reasons for this including social and technical ones.

Next month we are going to have a lunchtime session at work on stakeholder analysis so I did a little research on the topic and came up with a list of useful ideas.  They are posted below with some links.

I am thinking about:

• What does stakeholder mean?
• What boundary conditions help define who is and isn't a stakeholder
• Why analyse stakeholders?
• Techniques for identifying stakeholders?
• Techniques for analysing stakeholders?

Frameworks & thinking models

• The power/influence matrix
• Mapping stakeholder via KRAs
• Ranking stakeholder needs
• Networks of influence among stakeholders
• Integrating different analysis models
• The stakeholder circle model (more examples) from Mosaic 

James led a project team that was to investigate and address improvement opportunities for the online sales channel for a financial services organisation. The sales process was mapped and charts put up on the wall of the call centre, where most of the back office work was done.

Subject matter experts from the call centre were asked to inspect and comment on the chart, and to nominate suggestions and improvements. The analysts stood back and made o recommendation. Their contribution to the conversation was to elaborate and explain the diagrams and their notations, and to make corrections as frontline staff observed variations between the model and reality.

The operators identified several bottlenecks and activities that yielded little more than customer or staff frustration. The analysts captured the issues and documented them, later reporting them back via updated models.

By the time the documents had arrived two weeks later the frontline team had already taken action to streamline their process and optimise it for customer experience. Sales had already risen and without any further action the project could well have been called a success.