User Stories Revisited Part 1 – Myths and misconceptions

I’ve written previously about user stories, and I have compared them to other requirements techniques. Since then I’ve used them and seen them used in many new ways, some successful and some less so. I also often see people asking how to best use them, create them, develop them, size them and so on. I decided to dedicate a short series of blog posts to user stories.

The first, this one, will discuss common misunderstandings. Please at least skim it before reading the rest! After this post, I will provide some guidance on how to get the most out of user stories. The last in the series will discuss a very common question – how big is a user story?

But first, lets get some very common misconceptions about user stories out of the way.

Myth: If you’re doing Agile/Scrum/Insert framework here, you must use user stories

This is 100% false. Continue reading

Postpone technical details as long as possible, despite what your PM tells you

I’ve always been a firm believer that whether you’re Agile or Traditional, it’s important to postpone describing technical details as long as possible. It’s very tempting to start to solve problems ASAP, because there is something very satisfying about solving puzzles. Also, many project managers and others who are being held to deadlines will push to start design and coding as soon as possible. However, I believe in, as someone I met recently described it to me, a “back to basics” approach.

One challenge I often face is when a client pushes for me to start technical discussions with the users. Their argument Continue reading

When to use User Stories, Use Cases and IEEE 830 – Part 3: Requirement Statements

Requirement statements that begin with the phrase “The system shall” are often referred to as IEEE style statements, because they were recommended  for specifying software requirements in IEEE standard 830, and still are in 29148:2011.

The IEEE standard for software requirements specification recommends this method as they have many advantages  Continue reading

When to use User Stories, Use Cases and IEEE 830 – Part 1

A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.

Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading

Agile and the Analyst

I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.

As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to Continue reading

What’s the difference between a user story and a requirement?

I am often asked this when delivering training on writing requirements. The most obvious difference is semantics. A user story is generally written as a statement of something a user wants to do with a system and for what purpose. For example:

I want to find clothing that is my size.

While a requirement statement is traditionally written in a more formal style, starting with “The system shall” Continue reading