User Stories – Tell it like it is


At every training session I do on Agile and Scrum, there two questions that are guaranteed to be asked without fail. What are user stories? and Why are they called user stories?

Most participants understand that they’re some form of user requirement but 99 times out of 100 they confuse user stories with use cases. Requirements are probably the most important aspect of software development. If you get the software requirements wrong, then no matter how good your software development team is, the project is doomed to failure.

The problem

First and foremost, Software requirements is a communications problem. Clients or Customers need to communicate to the development team what they need built. Traditionally, requirements were written up-front and in detail and usually in the form of a requirements document. The problem with this approach however is that requirements are most often frozen or buried in these brutally hard-to-read documents. Not to mention the fact that requirements are often misunderstood due to imperfections in the written language.

User stories at their very essence are designed to solve this communications problem and to break down the barriers between the end user and the software development team.

Breaking it down

There’s lot’s been written about user stories by thought leaders like Mike Cohn. My own interpretation of a user story however is that there are two main parts – the “user” and the “story”

It’s really important to paint a picture for the development team about who is using the software. The type of user greatly influences the design of the functionality. So it is recommended that development teams spend some time defining user roles or personas and their description should be recorded in the description of the user story. For example:

As a “frequent flyer”, I’d like to be able to redeem my airmiles.

It is very interesting to see how personas are being used more and more these days. When I submitted my proposal for the Agile 2009 conference, I had to pick the persona that best matched my target audience. This really helps attendees to choose the talks that best match their level of Agile understanding. It becomes crystal clear.

Collaborating to elaborate

The second part i.e. the “story” part, is designed to tell the story. This should be written conversationally and is not meant to be very detailed. The reason is that in Scrum, requirements (or user stories) are fleshed out at the last responsible moment. And there is no better way to do this in person. It is meant to spark dialog between the customer and the team. And since this is done just prior to implementing it, you’re guaranteed to have highly relevant and fresh information. And since the Customer is supposed to be engaged every step of the way, this should never pose a problem.

Capture the details

Details are captured by way of user acceptance tests and should also be recorded along with the user story. Most tools like Agilebuddy provide a way for you to record and track acceptance tests. These acceptance tests are a way to inform the team how to know the feature is done. This is crucial. Responsible customers should execute the user acceptance tests prior to accepting delivery of the software

If you’re looking for more details on user stories the User Stories Applied by Mike Cohn is a great read.

Next week I’ll flesh out the details on user stories a little more. Please feel free to add color to this blog, share your experience and/or add your own interpretations.

“I know it doesn’t work but it’s done” – a story about the definition of done

Picture courtesy of orinrobertjohn@flickr

Some time ago I was talking to engineers responsible for some part of the software and I was asking when they will be ready for production. In other words I asked them when their features will be ready. They told me that they are ready now. What was my surprise when I tried to test their software and discovered that about 50% of cases were not working at all. So I asked them why they told me that they are “done” when they haven’t even implemented half of the planned features? They answered me: “We know it doesn’t work but it’s done – we implemented something so it’s done. Now we have to work on quality i.e. implement rest of the features.”

When I heard this I think I might have looked like the lady from the picture. I couldn’t believe someone can think like this – if we implement one use case out of one hundred we can consider the project done? The rest is the “quality”? I don’t think so.

In this post I’ll try to explain once again what is definition of done and why it’s so important to have the same definition at least among all the people involved in the development of a single project.

Let’s define “Done”

I would say that there is no one, good and universal definition of done. You can find some discussions in the Internet about it but you can see that everyone has it’s own variation. So do I – in my view the most important things are (I will use “user story” word meaning every variation of request, use case, user story, etc.):

  • user story has to be implemented, today (no 99.9% is accepted)
  • user story has to be tested and no known bugs should exist
  • user story is ready to go into production, today
  • user story has to be ready to be presented to customer, today

Some explanation

User story has to be implemented – means that the code has to be committed to the version control system (like CVS, SVN, etc.), documentation should be available on Wiki or in the VCS, etc. It means that the output of the work done (whatever the work to be done was) must be available for anyone in the company to be downloaded in some way and checked. There must not be “I have it on my box – will publish it soon”. Work must be committed and available for others.

User story has to be tested and no known bugs should exist – means that if you know about any bugs in the user story you’re going to deliver – it’s not done. If it exists in some subpart of the user story and you really need to deliver the working stuff, maybe you should split this user story into two, smaller ones. You must not deliver bugs to your customer – I’m talking about bugs you’re aware of.

User story is ready to go into production – it means that it is ready to be deployed at any time from the time you stop talking. The wise thing would be if the working software is already deployed and tested in the production system – if it works – it’s really done.

User story has to be ready to be presented to customer – it means that within 30 minutes (max) you are able to prepare presentation of working software to your customer. Of course, it requires you to have list of acceptance test ready and you know how to demo your software. The last point of it is very very important. Remember about it when defining all your user stories – you have to know HOW TO DEMO USER STORY – it will probably help you defining acceptance tests (e.g. user adds new item to the database using HTML form, then goes to the search panel and is able to find newly created item by its name, ….).

Wrap up

As I mentioned above good and universal definition of done probably does not exist but at least many resources agree on base principles. My definition of done is simple but I consider it quite powerful.

If you are interested in diving more into the subject I would recommend those two links from ScrumAlliance:

What do you think about my definition of done? If you have your own I would gladly read about it. Please share your opinions here.

My First Agile Project Part 11: A Tale of Two Dark Clouds

Picture courtesy of iowa_spirit_walker on flickr

And now, a story about physics. I’ll get to programming in a second though, I promise. In 1900 Lord Kelvin (of the Kelvin temperature scale among many other things) spoke at the meeting of Royal Institute in London. There was a consensus at the time that physicists had succeeded in discovering almost everything knowable about the universe. Kelvin was one of the believers in this idea and also one of the most powerful and influential men in science. His speech at the Institute was on 2 ‘dark clouds’ he saw on the horizon, 2 experimental results that didn’t fit in with what they knew at the time. Since they thought they knew almost everything, Kelvin was confident that these clouds would be found out and moved past sooner rather than later. What he couldn’t have known was that within the next decade, those 2 dark clouds would revolutionize not only physics but would literally lead to the invention of our modern world, including the computer you’re reading this article on.

Read on for how this story relates to Agile projects. Although if you’ve been on a sufficiently large project, you can probably see the connection between things on the horizon that seem small and end up having a huge influence on your project. In this part of My First Agile Project I’ll talk about a part of our project that seemed like a ‘dark cloud’ and ended up being a tornado tearing through our town.

The 2 dark clouds Kelvin was referring to in his lecture were the problems measuring the speed of the Earth around the Sun in what’s called the Michelson-Morley Experiment and the difficulty people were having in explaining “black body” radiation. These two experiments led to two of the most important discoveries in science, discoveries you may have heard of even if you’re not a science person: Einstein’s Theory of Relativity and Quantum Mechanics. This isn’t a science article and I’m not a physicist (just a ‘science groupie’ as Kevin Kelly says) so I won’t go into the whys and wherefores of these discoveries. But the fact that 2 unsatisfactory experiments led to theories that we’re still investigating today and to many, many inventions should be familiar to any one who has come across backlog items that blew out the schedule or required much more resources than originally estimated. It happens in every field and can break the assumptions and surprise even the smartest of practitioners.

Our Dark Cloud

On our project, our darkest cloud was generating invoices. Our project was to integrate a very customizable off-the-shelf billing system for the insurance company we work for. When we started, we had 3 documents we knew we would have to generate ourselves instead of using the built-in document generation in the billing system because they were too complicated. But even thinking they were complicated, the original plan was for one of our more experienced developers to use the invoice to come up with the system for generating the PDFs and then we would break up the work for the rest of the documents over the course of a few weeks. It turned out, however, that both our assumptions and those of the vendor were conflicting and wrong in different ways. We assumed that being a billing system, it would have built-in mechanisms for generating invoices. The vendor assumed that since every company has different requirements for invoices that each of their customers would naturally figure out their own way of pulling the data they need and generating the invoice.

Once we started into the development of the invoice and discovered that we would have to pull all of our own data from the system we doubled the time we thought we’d need for development of it. A developer from the vendor also started helping. After a while though, we were able to convince the vendor that they should give us a mechanism for pulling some of the data more easily and that would help their next customers as well. So now we could rely on them to make the logic match up between what shows on the screen of the system and what appears on the invoice. This helped with the complexity of the system immensely but by that time we had done so much of the work that converting to their new mechanism actually added time to the project. In the end this solution is a lot more maintainable though since we’re not duplicating their logic. Plus, the next customer to come along will owe us some thanks (we wouldn’t mind beers and/or money as well :)) for doing this work for them.

Invoices are just plain more complicated than we would have anticipated as well. A billing system has multitudes of different kinds of charges, credits, payments, reversals, writeoffs, and even things I still don’t understand like ‘negative write-offs’ which seems like an oxymoron but thankfully our Product Owner understands them. All of these things need to show up on the invoice, connected to the different policies the customer may have. We also need to make sure the invoice fits on the special perforated paper so the customer can tear off their bottom part and it needs to fit the envelopes and postal service requirements so they don’t charge us extra shipping. These are the tear-your-hair-out requirements you never learn until the last minute. Luckily this code ended up being developed by our most experienced programmer so even though there are what seems like a hundred corner cases for what appears where and when on the invoice, the code is easy enough to follow that I’ve made changes to it without having to spend all day figuring it out.

In the end, this particular dark cloud started out as something we thought would take one developer one sprint and is still not 100% complete after two developers have spent the better part of 9 months on it, including all the various things that have been discovered and added over time. Revamped invoices were part of the reason our company even decided to get a new billing system though so our Product Owner has given it the time it’s needed.

The reason I use Lord Kelvin’s ‘dark cloud’ metaphor is to show that even the best and brightest can underestimate what’s on or beyond the horizon, often in a big way. Accounting for dark clouds is what Agile does best though. In our case, the invoice is the biggest change our customers will see with the new billing system so it’s an important integration point that’s worth the effort. We’ve spent a long time on it but it’s definitely worth while and impressive as invoices go. We’re going to have less errors on these things than I get on invoices from my cell phone company, that’s for sure.

Thanks for reading and I hope this inside look at one big part of our development process was helpful. If you have stories or comments you’d like to share, please do so in the comments below. Thanks and stay tuned for more next week.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool – VersionOne
Part 10: 5 Important Issues For Teams

Six features of a good user story – INVEST model renewed

"As a Product Owner and the development team we want to have user stories of the appropriate size so that we could plan realistically while not wasting time on estimating and managing what would anyway will be changed" – A possible user story.

User stories are the the most used format for agile requirements. The main point of the user stories is to focus on the concrete user needs and not on figuring out the extensive amount details that are known to be difficult to gather upfront. A usual recommendation for stories to make more sense is to follow the INVEST acronym popularized by Mike Cohn in his books on user stories and on estimating and planning . According to these books and various online recommendations a good user story should be:

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Small
  • Testable

You can find more explanation on what each of the component means in the popular Vaibhav’s post. What I would like you to discuss today is the "small" component of the INVEST recommendation. According to it a good story shouldn’t be big, ideally no bigger, than 2-3 person-weeks of effort. That is indeed helpful for the team to work on the relatively small requirements. However, that recommendation is in the direct conflict with the product backlog iceberg concept that expects very detailed requirements on the top and rather huge requirements on the bottom that usually corresponds to the level of the requirement understanding. Requiring all the stories to be small

  • would be very difficult if possible at all for any large project
  • would project the false level of understanding of all the small requirements for the system
  • would require huge amount of estimation work much of which would be rendered moot as the requirements to any system inevitably change during implementation

Opinions change over time and lately Mike Cohn teaches the different INVEST model. According to it a good user story should be:

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Sized appropriately
  • Testable

In my opinion, that is a significantly better definition that I try to apply myself. An appropriately sized story on the top of the product backlog should be small enough for the team to realistically plan tasks for it. An appropriately sized story or epic from the further future should be bigger and the furthest stories can be really huge reflecting the level of the the detail understanding.

Your experience

How do you size your own requirements? Are you following any size-related guidelines to aid the planning?

My First Agile Project Part 2: Inception & Planning

Picture courtesy of ghindo@flickr

In the first part of this series about my team’s first Agile project, you read about some of the mistakes we made in only doing 80% of Scrum. In this part, I’ll talk about the initial Inception Phase of the project and about our Sprint Planning meetings. As usual, we did some things right and did some things we hopefully won’t do again. I’d love to hear in the comments how our experience compares to yours.

Inception Phase

The first part of our project was what we called the Inception phase, a sprint or so of basic requirement gathering. Some people call this phase Iteration Zero, a name that I like a lot for nerdy comic-book fan reasons. This phase was good and bad. For me it was good because I was fairly new to the company and I learned a lot about how the business works. For some background, I work at an insurance company and the project is to integrate a new billing system to replace our decade-old custom Oracle form app. Billing in insurance is fairly complicated; both insurance agents and insured companies are involved, there are deductibles, claims, premium charges, etc.

For a month, the senior programmer and I did almost constant meetings with various parties around the company, taking notes and trying to figure out where and how the billing system needed to integrate. This gave us a good list of what integrations we would be writing (talking to the claims system, printing checks, probably a dozen primary integration points overall) and what some of the customizations we would need to do were. What I didn’t like about this process was that we were directed to write integration documents for each integration point, including descriptions of what they did but also flow charts of program flow and a lot of detail we didn’t need. Being new, I did learn from these documents but nothing I wouldn’t learn again, or in some cases have to un-learn, later when we started doing more in-depth requirements gathering. Next time, we’ll do the meetings to get a handle on what integrations we have to do but we’re not going to do all the documentation again.

Since we were doing Scrum, we weren’t supposed to get too much detail in these meetings. “Snorkel”, not “Dive” was the direction given. Eventually though, you do need to dive deep to get enough to work with. A problem we had a lot was that our Subject Matter Expert / Product Owner had a lot to be expert on so she was incredibly busy all the time. We would assign tasks in the sprint planning meeting, then go get deeper on requirements gathering. This meant a lot of the time we were waiting on her and the people she needed to meet with to get enough detail to work with. If you’ve ever had to wrangle the schedules of more than 2 managers/directors in a company, you know how the days can fly by trying to get everybody in the same room.

I’ve since learned that the recommended practice is to make sure your SME starts gathering requirements for the next sprint’s tasks. This would have made things run a lot smoother. Since your backlog should be prioritized ahead of time, the SME should have a good idea of what’s going to get worked on next time even though it’s the team that decides. With a good base of details in place, work can usually start and intelligent questions asked once the clock is ticking on the sprint.

Sprint Planning

We did 4 week sprints on our project and we had around 10 developers, including 2 database experts for converting our old data. This meant that our sprint planning meetings ended up being all-day affairs. We tried a lot of things to shorten them but never really succeeded. As I mentioned in Part 1, we didn’t estimate difficulty on our backlog items ahead of time (a mistake, in case you missed Part 1). We had our list of integrations and known configuration changes, and it was somewhat prioritized. So in the planning meetings, the first thing we would do is take the top bunch of items and move them one at a time into the Sprint Backlog. As we did that, we would take our best guesses at who would do the work and how long that person thought it would take.

I know some people say you shouldn’t assign work directly to people in your sprint planning, instead assigning it to the team and letting people pick work off the team list. We didn’t feel like this would be the best plan. Even if we hadn’t done specific assignments, tasks would have mostly fallen on the same people anyway due to experience levels, specialties, etc. And when you assign to people, you have a better idea of how full everybody’s plates are. Of course it’s still a team and we all did our best to help out with everybody’s tasks so even though someone’s name was on something we all knew we should take or give tasks as needed. If you have people who don’t take tasks or appreciate the help, that’s probably Job 1 to take care of. Agile is largely about the team and if your team doesn’t work together, it’s a lot harder.

At first we didn’t do very much breaking down of stories into tasks since we were so new to the product and really didn’t know what each tasks would entail. Without a lot of good information about the tasks to go on, our estimates were hit or miss, honestly. Sometimes things that looked easy would run into some snag in the product and take 2 days. Sometimes things we thought might be impossible took 2 hours. (Being able to say “We thought this might be really hard but I got it done in 2 hours” is impressive during a demo, believe me.) Doing estimating on an integration project with an off the shelf product with an architecture of its own that you need to get familiar with is a different beast than green field development. You can know how to do something from scratch and have no idea how to do it so it integrates with somebody else’s product or APIs. It’s worth doing your best to figure it out though. If you start a sprint without a good idea of how much work something might be, you could spend all sprint just getting requirements nailed down.

Next Time

Once you’ve planned and done your tasks for the sprint, you need to show off what you’ve done and get feedback from the people involved. The next couple of posts in this series are going to be about our demos and issues of management buy-in and stakeholder involvement. What we did, the successes and failures we had at demos, and more coming soon. Thanks for reading and I’d love to hear your comments and experiences below.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End Of Our Project

Epics and Themes

User Stories are a not mandatory, but very recommended part of Scrum and eXtreme Programming methods. Most of people acquainted with agile software development feel comfortable with the requirements written in the form of “As a [user role] I want to [goal], so that [reason]”. Less people are acquainted with epics and themes usage.


Epics are just huge stories for capturing relatively low priority requirements that are often too complex to estimate right away and that are going to be detailed later. An epic for a car could be “As an environment conscious driver I want to be able to use both gas and hydrogene”. A theme on the other hand is a set of stories grouped around some functional area, user group or anything else that makes sense for the product owner. Themes are often confused with epics, because quite often the epic is split down into exactly one theme. A theme for a car could be a set of stories grouped around the building the hydrogen engine.

High level

Individual stories are good for prioritizing work between iterations and for negotiating during the iterations. However, for any non trivial project stories are likely to be somewhat too small and detailed for prioritizing on the high level – for preparing or rethinking the release plan. That is the point when epics and themes come into play. Both are for considering the project on the very high level. Your project might have 30 or 200 user stories of which 2-10 could be huge epics (possibly not all for the closest release) and the rest could be grouped into just 3-10 themes.

Epics and themes allow for the bird’s eye view of the project. The only real difference between epics and themes is in that epics are huge single stories often without a possibility for relevant estimates, while themes are the sets of stories (think rubber band of story cards as pictured above). Naturally, if the stories are grouped in such a way that part of a theme happens to be clearly less important, than the rest of it, after initial rough prioritization it might be needed to split a theme into several smaller sub-themes. Somesub-themes to go higher in the product backlog, some – lower.

Your experience

How do you use themes and epics? What do you find particularly useful or confusing about them?

Picture courtesy of hamed masoumi @ Flickr

When, How and Why Definition of Done Should Be Extended

Definition of done is one of the central concepts of Scrum process. Every iteration the team is supposed to release an increment of software that is fully done. Ideal Scrum team every iteration delivers software right to the customer hands, manages to arrange the trainings, print documentation and so on. Most of the real world teams, however, aim at somewhat smaller goals. What exactly is expected to be delivered by the iteration end depends on the team’s definition of done.

Evolution of Done

There are different checklists and recommended definitions of done. However, there is no best definition that can be used by all the teams in the world. It is especially difficult to choose a reasonably wide definition during the transition phase from the traditional plan-driven methods, because in such situations the final testing phase of delivering software might easily take longer than half of the sprint.

There is no universal recipe for choosing the good definition, but as a rule of thumb it might be useful to adopt the very minimal possible definition from the beginning and then iteratively widen it. The point is to standardize what the team is actually able to reach and improve in the controlled manner without “adopting” standards the team is not actually able to follow. The minimal definition might be as loose as “Product Owner has to explicitly accept the delivered backlog items”. Then it can be widened with e.g. “some automated tests included”, “critical code code reviewed”, “all the changes are developed in the test-driven mode”, etc.

Your Experience

How do you see the evolution of the definition of “done”? Where did you start and how much does your definition change over time?

Six Features of a Good User Story – INVEST Model

What is a User Story?

A user story describes desired functionality from the customer(user) perspective. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. The basic components of a User Story are sometimes dubbed as the three C’s:

  1. Card – the written description of the story, serves as and identification, reminder, and also helps in planning.
  2. Conversation – this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.
  3. Confirmation – the acceptance test criteria that the user will utilize to confirm that the story is completed.

A user story is not technical.

A well-written user story follows the INVEST model

Independent, Negotiable, Valuable, Estimable, Small, Testable. Let’s see what each one means:

  • Independent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.
  • Negotiable – A user story is negotiable. The "Card" of the story is just a short description of the story which do not include details. The details are worked out during the "Conversation" phase. A "Card" with too much detail on it actually limits conversation with the customer.
  • Valuable – Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realizes that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.
  • Estimable – The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).
  • Small – A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.
  • Testable – A story needs to be testable for the "Confirmation" to take place. Remember, we do not develop what we cannot test. If you can’t test it then you will never know when you are done. An example of non-testable story: "software should be easy to use".


Well-written User Stories are cornerstones for Agile Development. They should be independent of each other; the details should be negotiated between the users and the developers; the stories should be of value to the users; they should be clear enough for developers to be able to estimate them; they should be small; and they should be testable through the use of pre-defined test cases.

Product backlog

Update: See also section added

Product backlog in Scrum is simply a list of things needed to be done. As such it is a little different from many other to-do lists. The difference comes from the small peculiarities of the way you handle the backlog. Here some some things to note about the product backlog.

  • Product backlog always lists items adding value for the customer. It includes functional requirements and non-functional requirements. It can also include items required by the team, but only the ones that will eventually bring value to the customer, e.g. taking into use a continuous integration server in order to guarantee the continuous end product quality.
  • Product backlog cannot include concrete low level tasks and requests for building the intermediate artifacts. For example, it cannot include request for producing the design document unless customer has to ship it further for some purpose.
  • Product backlog utilizes the simplest and the most effective way for prioritizing requests – a simple list. Such a method does not allow for having 100 absolute max priority features and forces the product owner to actually make decisions about the feature priorities.
  • The higher the items are located on the product backlog, the more detailed they are. Items for the closest couple of months are usually quite detailed, while items that will be worked on in some 6-12 month can be defined very broadly and imprecisely.
  • When there are several interdependent teams in the company or department, typically they all have a single product backlog and pull their work from it.
  • Product backlog does not typically include the detailed requirement information. Usually the final requirement details are figured out with the help of the customer, when the requirement is being implemented.

Ease of use, clear and transparent purpose is what makes the product backlog so useful for seeing into the project status.

See Also

Do you agree with the properties above? Or are there any other important product backlog properties worth mentioning?

Conditions of satisfaction

Agile teams try to avoid the over-detalization of the customer requirements. In many cases the initial requirements are specified as loosely as in one sentence. In order to keep focus on the real customer demand (and not on what dialogs he’d like to see) the feature requests are often expressed in a form of “As a , I want [so that ]”. For example, “As a network administrator, I want to monitor the most active nodes of the system so that I was able to easily balance the load”. This form of requirement works very well until you start to work on it. It allows for capturing the original user need, while delaying the implementation specifics as long as possible, so that the team was able to work on it with as much information as possible.

At the iteration start, when the team selects user stories or features to be implemented, the requirements have to specified in the bigger detail, while still omitting as much implementation as possible until the actual start of the development. The agile term for these additional level of details is “conditions of satisfaction”. For the above administration requirement example conditions of satisfaction might specify which parameters of the system the administrator needs to monitor (e.g. processor load in %, free network bandwidth in KBits per second) and how would he like to monitor the system (e.g. be notified by SMS, see the load himself when running the administration panel).

There are couple of simple questions that can aid creating the helpful conditions of satisfaction (adopted from Writing Contracts for Agile Development )

– How will the team know we’re done?
– When the team demonstrates this feature to you what would you like to see so that you know the team has done what you expect?

When do you usually specify the requirement details and what level of detail do you find useful?