For years, I've given Software Testers in my teams the official job title of Test Analyst, or something along those lines.

Yet (informally) I've always referred to them as Testers.

Only in more recent years - and especially since adopting Agile Software Development and User Stories - have I really discovered how to put the *Analyst* into Test Analyst.

I've written before about 'Why Agile Testers Should Be Involved From The Start'. It's obviously very important in agile development, and has a number of very good benefits.

With User Stories, we've gone a step further.

A Business Analyst, Product Manager, Product Owner and/or the Team should identify the relevant User Stories for the Product Backlog. From this feature list, for the selected items for the next Sprint, requirements need to be clarified and expanded on.

The requirements for each User Story should be discussed and clarified as a team. But, in my view, the Test Analyst is an ideal person to lead this discussion and write up the User Story cards.

Test Analysts tend to be very analytical in their nature. They tend to be good communicators. And, as we all know, they can think of scenarios that business people and developers never even dream of! :-)

Moreso, when it comes to writing test cases on the back of the User Story card, they are obviously the ideal person to do this. Writing these test cases up-front, when the feature is being defined, helps to improve quality from the outset, as developers are more likely to write their code to pass the tests (because they know what they are).

But also, it makes perfect sense to me, for the person that's going to test a User Story, to be the person that defined it.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by p0psicle

read more

Over the last few weeks, I've written a lot about how to write good User Stories. You can see them all here: Writing good User Stories.

User Stories are a simple way of capturing user requirements throughout a project - an alternative to writing lengthy requirements specifications all up-front.

As a guide for people writing User Stories, they can follow this basic construct:

As a [user role], I want to [goal], so I can [reason].

This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why.

As well as capturing User Stories in the above format on the Product Backlog, User Stories should be written on a card.

The card comprises 3 parts: Card (the bit above), Conversation (notes and/or small wireframe to remind people about the feature), and Confirmation (the tests that will show the feature is complete).

Here's an example User Story for you to take a look at.

Ultimately, User Stories should be small. But when they're first entered on the Product Backlog, when they're quite a way from being developed, they can start out large and fuzzy. While they are in this state, they are known as Epics.

Software requirements are a communication problem. There is no perfect solution. User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.

Here's a PowerPoint presentation about User Stories to help share the concept with others.

The INVEST acronym can help you to remember and assess what makes a good User Story. User Stories should be:

* Independent. Okay, for some systems, it's near impossible to make each feature completely independent. In other solutions, e.g. web sites, it's easier. But it's an important aspiration. User Stories should be as independent as possible.

* Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

* Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

* Estimatable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

* Small. User Stories should be small. Not too small. But not too big.

* Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

I hope this series of posts has been useful. If you want to browse through all these posts about User Stories, you can do so here: Writing good User Stories.

Kelly.

read more

The *T* in the the 'Invest' acronym (a way to remember and assess what makes a good User Story) stands for Testable.

The most common forms of User Story that are not testable are big User Stories, known as Epics, or non-functional User Stories...

An Epic can be a User Story that really comprises multiple User Stories. Or perhaps an Epic can also be a User Story that is very complex.

An example from my previous job might be something like: "As a user, I want to calculate the cost of repairing a crashed car". This is really an Epic and is not really Testable.

Non-functional stories are things like "As a user, I want the system to be fast", "As a user, I want the system to be secure", "As a user, I want the system to be easy to use". None of these things are well written from a Test perspective. Perhaps they could be re-phrased to make more Testable? For instance, "web pages should generally load within 2 or 3 seconds", "the system should comply with OWASP security standards"...

Let's take my recent Example of a User Story to see if it's Testable?

First of all, it's small and fairly independent, which makes it inherently more testable to start with. This is a simple example so it should be easy to test. The scenarios are: Successful login, Failed login (user id), Failed login (password), Failed login (expired account), Failed login (authentication system unavailable), Remember me (if successful and ticked).

Importantly, identify the tests up-front, before the User Story is implemented. If developers know how the User Story will be tested, maybe they will write it to pass? :-)

Kelly.

read more

User Stories should be small.

This is what the *S* stands for in the the 'Invest' acronym; a way to remember and assess what makes a good User Story.

Not too small. But certainly not too big. So what is the right size for a good User Story?

First of all, let's get one thing straight. This statement is slightly misleading. More accurately, it should read: "User Stories Should Be Small, by the time you plan to include them in a Sprint".

Because until you come to Sprint Planning - until you're ready to include the feature in the next iteration - User Stories can be big. In fact, they can be huge. Humongous even! It's completely reasonable for User Stories that are further down the Product Backlog to be rather large and fuzzy.

As long as they are broken down before it's time to work on them, that's fine. They are still effective placeholders. So it's okay to have a User Story further down the backlog like: "As a user, I want a new system, because the old one no longer meets my needs".

These big User Stories are known as Epics.

Anyway, back to the point in hand. What's a good size for User Stories when they are ready to be developed?

Let's take my recent Example of a User Story. This could have been: "As a user, I want to register, log in and manage my details online". But I think that's too big to be a good User Story. Perhaps it started life like that, as an epic, further down the backlog. That would be fine. But at the time of Sprint Planning, a story like this should be broken down.

So let's say it's broken down into 3 stories: register, login, and manage details. The login story could potentially be broken down further, into another 3 stories, for example: login, forgotten password, remember me. In my opinion that's a nice size. The stories are very focused. Small. But still each story is still functional and fulfils its own purpose. And they're still fairly Independent.

Now let's say the login story is broken down even further. For example: "As a user, I want to enter my user id", "As a user, I want to enter my password", "As a user I want to push the login button", "As a user, I want a clear error message when my login fails", etc. Then I'd say it's gone too far. These stories are too detailed. At this level, even a small project would end up with hundreds of stories, and be very hard to manage.

In the end, there's really no right or wrong here - you need to do what feels right for you and your team. Nevertheless, I hope my comments offer some useful guidance, even if it's just as a starting point for your team to debate...

Kelly.

read more

User Stories should be possible to Estimate.

If you follow the other aspects of the 'Invest' acronym, chances are they will be. The *E* in 'Invest' stands for Estimatable; another useful way to measure whether a User Story is good or not.

So what are the potential barriers to a User Story being Estimatable?

Too big?

Maybe the story is too big? In this case, simply break it down into multiple User Stories, until it is more reasonable to estimate.

Not enough information, or requires domain knowledge

Maybe there is not enough information, the story is too vague, or requires domain knowledge to properly understand what is meant? In this case, there are 2 aspects of the Scrum agile development method that help with this issue...

Firstly in the Sprint Planning Workshop (Part 1), discuss the requirement as a team with the Product Owner and/or user representative. Do not attempt to estimate it until you feel you have clarified it enough to really understand the requirement. Capture some further information or notes on the User Story Card.

Secondly, in the Sprint Planning Workshop (Part 2), break the requirement down into tasks; ideally tasks of less than one day. Do this as a team. Breaking the requirement down will obviously help to estimate it. Breaking the requirement down into tasks of less than one day will make each task more predictable and the estimate is likely to be more accurate as a result.

Doing both parts of Sprint Planning just in time, just before a Sprint, and involving the whole team, will help to ensure that everyone on the team understands the requirements. And, importantly, the information will still be fresh when the feature is being developed and tested.

New technology or not enough knowledge in the team

Another potential barrier is that the product or specific User Story may involve new technologies that the team has not worked with before. First this means the team will be less productive and may not be able to rely on their past experiences. Second it means the team simply may not know how to implement it.

In this case, someone in the team needs to be able to complete a brief research task before the User Story is estimated. This research needs to be time-boxed and they need to do only enough research and/or prototyping to estimate the work more reliably. This should ideally be done during the Sprint Planning cycle if at all possible, or if it's going to take longer should be done early in the Sprint before the story is committed in the Sprint Backlog. It's worth having a few User Stories in reserve, either as stretch tasks or in case the research determines the story cannot be accommodated in the current Sprint. In Extreme Programming, this research task is called a 'spike'.

So, now let's look at my recent Example of a User Story and see whether or not it feels like it's Estimatable?

It's certainly not too big. It's very familiar and doesn't require any domain knowledge. We all know how to log in to systems and know what to expect. I don't think it's vague. In fact, I think it contains quite a lot of information for such a small card. Technically it's straightforward. And in our case it was being developed in familiar technology. So I'd say this example is dead easy to estimate, so the story - at least in this respect - is good.

Kelly.

read more

I recently quoted the 'Invest' acronym as a way to remember and assess what makes a good User Story.

The *V* in 'Invest' stands for *Valuable*.

It is often said by people in the agile community that User Stories should be of value to the user.

Whilst that is mostly true, some User Stories are not of value to the user, but rather of value to the customer or owner of the system.

Therefore it is more accurate to say that, "User Stories should be of value to the user, or owner, of the solution".

A good example of this is advertising space on a public web site. Ads can be of value to the user, if they are highly relevant and positioned in a place sensitive to the user experience. For example on Google. On the other hand, very often the ads on a web site are of little value to the user and interfere with content, creating a poor user experience. Of course I would never advocate creating a poor user experience, but regardless of the debate about value to the user, they are certainly of value to the owner of the solution.

User Stories should be focused on features - not tasks. And written in business language. Doing so will enable business people to understand and prioritise the User Stories.

For example, a User Story to 'comply with OWASP security standards' should be written something like this: 'As a user, I want my data to be secure, so I can use the system without my personal information being misused'.

This brings me to the question of non-functional User Stories that in effect span all other User Stories. For example the above story about security, or maybe a user story about the solution's performance. These can be captured as User Stories to ensure the requirement is not lost. But actually these requirements are possibly better served by writing a series of standard test cases to be applied to all User Stories.

So let's take a look at my recent Example of a User Story in terms of being Valuable to the user or owner of the solution? An agile consultant saw this example and said it was not a good example because logging in to the solution is of no value to the user.

But in this case I disagree.

It is of value to the user, because only by logging in can they gain access to features and content that are available to subscribers only. And it's also of value to the owner, as it prevents people from accessing premium areas of the solution unless they have paid to subscribe.

Kelly.

read more

User Stories are not a contract. They are not meant to be precise, detailed specifications of a feature. They should not be fixed in stone.

I recently quoted the 'Invest' acronym as a way to remember and assess what makes a good User Story.

The *N* in 'Invest' stands for Negotiable.

A User Story is a reminder. A reminder to have a conversation about a feature. A reminder to collaborate in order to understand the details just in time for the feature to be developed. Notes can be made on the User Story Card as details are captured and clarified.

A User Story should have sufficient information to capture the essence of a feature without requiring too much collaboration for the basics.

However, a User Story should not contain too much detail. Too much information can imply that the User Story is complete and precise.

So much more information can be gained from a conversation because of the rich, two-way nature of a verbal exchange. Too much information on a User Story can cause people not to collaborate, believing they already know everything they need to. Then you lose out. You lose out on the advantages of combining a written reminder with a verbal, face to face communication.

One of my 10 key principles of agile development is that 'agile requirements are barely sufficient'. Suffient. But barely. No more information than is necessary to proceed with development and testing with reasonable efficiency.

Sometimes a requirement may have been 'specified' in a particular way, and a developer finds that it's awkard to implement. Or that there's an easier alternative. In these cases, a small compromise, or a slight change in approach to the feature, can simplify and speed up the implementation. User Stories should be Negotiable, so no time is wasted when the user or customer's goals can be met an easier way.

So, using the 'Invest' acronym, how does my recent Example of a User Story look in terms of being Negotiable?

Perhaps it's a bit detailed? It implies a particular design approach to the functionality behind the button. Although this is really just a note about a key decision for the design approach that should be adopted; there is no detail on the design of the feature itself.

The visual approach implies a specific screen layout, although it's meant to be a wireframe rather than a screen shot. Personally speaking, as long as people treat it as Negotiable, I think a picture is worth a thousand words and this is well worthwhile.

This example is possibly as detailed as a User Story should really need to get. Certainly I wouldn't expect to see every User Story as detailed as this. Many User Stories could probably be described with less detail. And still be (barely) sufficient.

read more

In my last entry, I quoted the 'Invest' acronym as a possible way to remember and assess whether or not User Stories are good.

The *I* in 'Invest' stands for Independent. Ideally a User Story would be as small as possible, without making it dependent on other Stories.

I recently posted an Example of a User Story. In the next few entries, I'm going to use the 'Invest' acronym to assess whether or not this example is any good?

So, first, let's take a look at whether it's Independent? Personally I see a problem already. In my example of a User Login story, I included a link for 'Forgotten Password', but this is actually a separate story that isn't covered on the card.

When I did this example, I deliberately didn't include the forgotten password feature, in order to keep the story small and fit it on the card. But I did put the forgotten password link on as a reminder of the related story.

If a developer implemented this story as per the card, the forgotten password feature would be a broken link until the related story was implemented. If the Sprint or iteration had finished with the Login story completed and not the Forgotten Password story, the product would not be shippable. Therefore this is not a good example of a User Story that is Independent.

If, however, I had left the link off of this story, and included it on the Forgotten Password story instead, the Login story could have been implemented in its entirety without reliance on other features that may or may not be completed.

So, unfortunately for me, I've failed on the first test! My example User Story is not Independent and the 'Invest' acronym would have helped me spot that straight away. I wonder how I'll do on the other points?

Kelly.

read more

User Stories are certainly an easy concept. But what makes a Good User Story?

That's a bit of an open question. I'm sure everyone has a different opinion of what good looks like.

But there are certainly some common characteristics of a Good User Story.




Bill Wake, author of 'eXtreme Programming Explored', suggests this 'INVEST' acronym as a simple way to remember and assess whether or not a User Story is well formed.

Good User Stories should be:
* Independent
* Negotiable
* Valuable
* Estimatable
* Small
* Testable

Personally I'm not really a big fan of management acronyms - they can be a bit cheesy. But I do like this one. I think it's very helpful for people new to writing User Stories to remember and assess what makes a Good User Story, particular as User Stories are such an open format.

Kelly.

read more

Here's another PowerPoint presentation for you - Introducing User Stories...

To get your copy of the presentation, please click here.

For more presentations, see also:

* 10 Key Principles of Agile Software Development

* Implementing Scrum

If you find this presentation useful, please tell people about my blog... Thanks!

read more

Let's face it. There is no perfect solution. No perfect solution for humans to share information accurately, consistently between multiple people, and over a prolonged period of time.

Especially when you add into that equation the level of detail that's needed to capture the requirements for a major software application.

And then there's the complexity of software. And the fact it's plyable. Its evolutionary nature means it simply isn't comparable to the creation of many other products. And certainly not comparable to construction projects, where once built the requirements are literally fixed in stone.

Software requirements, therefore, are a uniquely challenging communication problem. Such a challenging problem, we mustn't kid ourselves into thinking there's a solution. Personally, I am pretty sure there is not.

However, there are ways of mitigating some of the problems, whether it's in written or verbal form. Let's look at some of the pros and cons of each...

Written Requirements
–can be well thought through, reviewed and edited
–provide a permanent record
–are more easily share with groups of people
But, are:
–time consuming to produce
–may be less relevant or superseded over time
–can be easily misinterpreted

Verbal Requirements
–provide opportunity for instantaneous feedback and clarification
–are an information-packed exchange
–can be easier to clarify and gain common understanding
–are more easily adapted to any new information known at the time
–can spark ideas about problems and opportunities
But:
–are spur-of-the-moment and not always well thought through
–are harder to share across groups of people, particularly if not co-located
–conversations can be remembered differently by different people

Whichever form of requirements capture you prefer, we must all remember the old addage: "A picture is worth a thousand words". It's so true. Whether it's a diagram in a spec, or a sketch on a whiteboard, pictures add a dimension that is immensely valuable.

The approach of User Stories seeks to combine the strengths of written and verbal communication, supported by a picture where possible. See here for an example of a User Story Card.

And some key principles of agile development seek to address some of the weaknesses of both forms of communication, in an effort to create a best of both worlds:

• Active user involvement to ensure continuous visibility and feedback
• Agile teams must be empowered to make decisions, so details can be clarified at the time of development
• An acceptance that requirements emerge and evolve as the software is developed
• Agile requirements are 'barely sufficient', so they are not too onerous to produce and the latest information can be incorporated at the time of development
• Requirements are developed in small bite-sized pieces, so details can be captured verbally whilst minimising the risks of people forgetting details or not being involved when the requirements are developed
• Enough's enough - apply the 80/20 rule; capturing every detail isn't necessary to produce a quality product; verbal clarification, visible software and feedback works better
• Cooperation, collaboration and communication is essential between all team members, as everyone involved must know the outcome of any discussions about requirements.

read more

When putting User Stories onto a Product Backlog (or feature list), you shouldn't feel compelled to break everything down until the features are nearing development.

Further down the Product Backlog, it's fine for items to be fairly fuzzy. It's also fine for items further down the backlog to be whole projects - large, high-level items that are not so much User Stories but more like Epics!

As an item nears development, the item should be broken down further. And as it nears development, the item on the backlog should be defined in sufficient detail that the team can reasonably estimate its size and break it into tasks.

Until that time, however, it's just really a placeholder. A reminder for prioritisation and high-level estimating. That's all.

For some people, particularly those used to a more traditional project approach, used to detailed specifications up-front, this can potentially feel very uncomfortable. It shouldn't.

The logic here is simple. There is little point defining a feature (or set of features) in detail if it may never reach the top of the priorities. The other aspect of this logic is that you tend to know more about your requirements, constraints, etc as time goes by.

And things change. People come and go. Sometimes the team has changed significantly since the original requirements emerged, so information can be lost if it is captured too early.

Therefore it makes business sense to defer details until they are needed.

read more

I recently described User Stories and the composition of a User Story Card - Card, Conversation and Confirmation.

I'm not really sure if you would consider this example to be good, bad or indifferent - I guess it depends what you're used to - but here is an example nevertheless!

This is the front of the card.

The Card section describes the user story. The Conversation section provides more information about the feature.

Note the feature (for a user to log in to a web site) is small, so the story can be fairly well described on a small card.

Clearly it's not as detailed as a traditional specification, but annotating a visual representation of a small feature at a time, makes it fairly self explanatory for team members.

And I would certainly argue it's more easily digestable than a lengthy specification, especially for business colleagues.

Here is the back of the card:

The back of the card outlines the test cases for this feature - how it's going to be confirmed.

Whether or not these are the right scenarios, or cover all possible scenarios, isn't really the point of this example.

The point is that the test cases for this feature are written on the back of the card, in support of the information about the feature, and before the feature is developed.

Generally speaking, there is a very fine line between a requirements scenario and a test case, so it isn't necessary to capture too much detail on the front of the card and clutter it up. The card in its entirety represents the requirements for the feature; whether captured in the Conversation section or the Confirmation section.

Even the description of the user story in the Card section carries some important information. In this case, there is a pre-condition (the user must be registered) and a post-condition (the user can access subscriber-only content). All of the card must be read to get the whole story.

Importantly, the User Story is expressed in business language, and in a micro, more easily digestable, information-packed format.

read more

If you're capturing user requirements using User Stories, write them on a postcard... (a blank one of course!).

A User Story Card should ideally comprise 3 parts: Card, Conversation and Confirmation...

Card
The heading section of the card should include the name/description of the user story, any reference numbers, estimated size, etc.

Conversation
Most of the front of the card should include further information about the user story and what the software is meant to do. This can be a sketch or diagram of the feature, or notes about how it should function. Anything that helps to concisely explain the feature. Remember this is a reminder of the story and notes about it, not a full specification on a card. The team should collaborate to get more details at the time of development.

Confirmation
Write test cases on the back of the card. Writing tests up-front helps to ensure the software is designed to pass. Writing tests up-front also helps to identify scenarios that users, developers and/or analysts may not have thought of.

Keeping User Stories small enough to fit on a card helps to ensure that requirements are broken into small, manageable pieces of functionality, i.e. individual features.

Cards also work nicely in conjunction with whiteboards, providing clear visibility of progress and enabling team collaboration, moving cards around the board as things progress.

read more

User Stories are a simple way of capturing user requirements throughout a project - an alternative to writing lengthy requirements specifications all up-front.

User Stories are derived from XP (extreme programming), however they can just as easily be used for requirements gathering in any agile development methodology, or indeed in any home-grown development process.

A User Story is a simple statement about what a user wants to do with a feature of the software, written from a user's perspective. A User Story should not use technical jargon or state design goals. User Stories should be written in business language that is understandable to all.

A User Story should focus on the who, what and why of a feature, not how.

For example, on a job site, two high-level User Stories might be:

• As a job seeker, I want to search for a job, so I can advance my career.
• As a recruiter, I want to post a job vacancy, so I can find a new team member.

read more