125

I think one of the main advantages is that humans and developers specifically are actually pretty bad at estimating time. Think of the nature of development too -- it's not some linear progression from start to finish. It's often "write 90% of the code in 10 minutes and then tear your hair out debugging for 17 hours." That's pretty hard to estimate in the ...


58

If you're using Fibonacci numbers (or something similar), it limits the number of options when estimating a story. I worked with a group that used low numbers only: 1, 2, 3, 5, 8, and 13. We had a reference story that was a 5. This enabled us to easily make snap decisions on a story's complexity while doing Planning Poker. The other side effect was that ...


55

User Stories are not system specifications or functional requirements. Rather, they are the beginning of a conversation that can lead to such specifications or requirements. Accordingly, I would expect there to be overlap in the system implementation. User Stories are not meant to describe such functional overlap or to eliminate it. The purpose of User ...


54

Ideally, your software should be bug-free after each iteration, and fixing bugs should be part of each sprint, so the work required to fix bugs should be considered when assigning story points (i.e., a task that is more likely to produce bugs should have more story points assigned to it). In reality, however, bugs surface post-deployment all the time, no ...


49

To be honest, after spending close to two years immersed in Agile development, I still think "user story" is just a fancy term for "functional requirement". It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in ...


26

The trick is not to avoid there being blanks. The trick is to fill in those blanks as early as possible in the process of development. You are correct that, if developers make assumptions, they will invariably be wrong and that will cost time redeveloping the software later. But, equally, if business people are expected to do a full up-front design when ...


24

If paying money affected customers negatively, they wouldn't be using that service. Don't worry about this. Also, users don't (usually) pay money because they want to help out system owners, but because they want some service in exchange, so your example should really be like this: As a customer, I want to be charged every time I check my email so that ...


24

It's to enable estimation to get better over time, without the estimators all having to adjust their estimation. Rather than everyone involved in the estimate having to think like "OK.. looks like 2 man days.. but last sprint we underestimated everything, so maybe it's really 2.5 man days. Or 3?", they carry on the same as always. "5 story points!" Then, ...


19

The purpose is to avoid unnecessary work by forcing the user/customer to supply a solid, tangible business benefit as a reason for the existence of this feature. It is not unheard of that features get added just because someone thought they sounded cool, or because other software has it, so ours must have it, too. More often than not, those are at least ...


19

Estimating bugs with points is inherently difficult as already pointed out in other answers and yes the ideal solution is that bugs found in a feature AFTER the sprint has been accepted should be considered new features. This difficulty in point estimation for bugs however is one of many reasons that Agile PM software packages allow for tasks and bugs to be ...


18

You should not give points to bug resolution. Consider the fact that the bug comes forth from a story where the developers already earned points for completing the story. It should not receive points again where it actually shouldn't have earned the points to begin with. Bug fixing should have a negative effect on velocity. Otherwise dropping quality ends ...


17

Man days or man hours are as you say concrete. So when a task is estimated at 5 hours and takes 6 it is now a late task. When you have a story that is a 3 points and it takes 6 hours, it took 6 hours, it's not late, it just took six hours. The velocity measurement than is more a factor of how many of those points you get done in a sprint, and that number ...


17

People use the terms "business rule" and "business logic" to refer to the portion of your application that is specific to your application and represents the core behavior of how things are supposed to work as opposed to generic functionality that could be useful in software written for a different client/business/customer base or code that exists to support ...


15

You need to estimate each story once you have fleshed it out - this assumes that you are getting your stories in order of priority and that they are elaborated enough for development. When you have estimated enough for an iteration, start coding.


15

What's wrong with e.g.: As a sales assistant, I want the system to generate my invoices raised during the day, that night without my interaction so that time is saved. Think of who will use the results of the process.


15

Yes, it is a good idea to give your tests names of the example scenarios you are testing. And using your unit testing tool for more than just unit tests maybe ok, too, lots of people do this with success (me too). But no, it is definitely not a good idea to write your tests in a fashion where the order of execution of the tests matters. For example, NUnit ...


15

Recently, I had the "pleasure" of producing three separate prototype solutions for a problem our company has related to reports and presenting them to my bosses. Each had its share of advantages and disadvantages in terms of development time, performance, scalability (time between start of project and being able to begin producing reports), ability for ...


15

Ron Jeffries wrote a long time ago about the 3Cs of user stories (http://xprogramming.com/articles/expcardconversationconfirmation/) with the emphasis on a card (short description), conversation between the customers and the delivery team once a user story becomes actionable, and the agreed confirmation of a story after that conversation. essentially, ...


15

Don't: Try and split the stories, Do one story and then the other. Do: Ensure the dev team is aware of the second story. The problem with trying to plan out the detailed tasks and thing up a generic model that can handle both in an elegant way is that it's hard. The purpose of user stories is to get stuff done. Elegant is a secondary objective and should ...


14

Yes you will build database incrementally by adding required tables and columns as they are required by the story. You usually don't need the whole database when you start your first story - for example "As a user you must be able to register ..." most probably requires single table with exactly defined set of columns. If you have a story which really ...


14

"As a user of X, I need to know how X works" seems like a legitimate user story to me. This could result in written documentation or online help. The point isn't just code--it's meeting the users' requirements.


14

Baby steps. Continue to write the SRS for a while. Then call a meeting and discuss whether they still serve a purpose. Does anyone still read them? Is the time spent on them justified? Is there another intermediate step that would be more lightweight? You never know, you might find that you're wrong. Remember the Agile manifesto, we find more value in "...


14

Your examples can count as user stories, but they are missing a very important part: the goal that the user wants to achieve when the story is implemented. This goal might be obvious to you, but you should write it down anyways. A user story has the format As a <user> I want <feature> So that <goal> The goal part is important, because it ...


13

The abstraction is sort of the point. Using the 'man day' as a measurement has a number of pitfalls, including: If the team isn't familiar with the tech they are going to be using, then it can be really hard to give real-time estimates of how long a task might take. They are much more likely to be able to give good relative estimates - e.g. "task A will ...


13

Take it iteratively. You're working directly with the users, right? So it should never really be a mess. First do the search page. You and the users should keep in mind that they'll want to be able to do actions on the results. Do the users like it? OK, you've got your search. Now add the "Change Password" (or whatever is next in priority). Oops, we ...


13

You're definitely doing a time based estimation, hence, no story points in the original sense. Story points are meant to be an abstract measure for relative estimation of story complexity. The mapping to an amount of time only happens implicitly, when you pull a certain number of story points into your fixed-time iteration. Here's an interesting discussion ...


13

Technical stories are allowed, but I would advise you to try to avoid them as much as you can. For example, your story for saving and retrieving images can easily be written as two regular user-stories As a reviewer, I want my uploaded photos to be stored persistently, so that other users can view them at any time. (Note that this assumes that in your ...


13

I like the other answers that say to put as much "tooling" code as you can into Iteration 0. However, sometimes, these kinds of tools come up after the project has already started. Perhaps in Iteration 3 you realize you need a generalized XML parser widget to be used on various stories going forward. In that case, the first User Story that relies on these ...


12

We thought about this problem quite a lot in the past year. While I agree that a basic framework should exist before the project starts, in practical use it can be part of the project itself. So you have to manage somehow. While mixing project setup with user stories might make sense sometimes we have settled on simple tasks that can be added to the ...


Only top voted, non community-wiki answers of a minimum length are eligible