Tag Info

Hot answers tagged

84

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 ...


39

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 ...


26

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 ...


25

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 ...


16

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, ...


16

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

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.


14

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 ...


13

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.


13

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 ...


13

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 ...


13

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 ...


12

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 ...


12

"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.


12

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 ...


12

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 ...


12

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 ...


12

Usually you would create user stories along these lines: As a user, I want the transition from X to Y to happen in less than Z seconds. As a user, I want X to be responsive. As a server administrator, I want our server to be able to handle X simultaneous requests. Note that the 'user' in user story doesn't always have to be a paying customer. As long as ...


12

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 ...


11

The <user> does not have to be the end user - it can easily be the business owner/system owner: As a system owner I want to charge customers So that the business can pay my programmers


11

This seems to be a social problem, so it will need a social solution. If (as I understand you) backend developers feel ignored and slighted, and feel that their work is not valued enough, then there is little that the development process can do to change this. If I understand correctly, I looks like the devs feel that they should at least have their "own" ...


11

If you keep it as one single user story and you only get 4/5 filters done at the end of your sprint, then your single story is incomplete. If you split it, then if you get 4/5 filters complete, then 4 out of 5 stories can be marked as finished. When I get stories like this, that have n features of a similar nature (such as your 5 filters, or some ...


10

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 ...


10

This might be controversial but here it goes! We have worked on a real time systems where one of the past bosses of mine suggested that let's do AGILE! It was easy to win management on that really; however, it was easier said than done. The concept of stories is good - but to be very upfront, it is quite vague. What is a story, really? The real issue is ...


10

I've never seen anyone estimate the entire product backlog. Typically what happens is that the product backlog is prioritized. The team takes off the top story, estimates it, and puts it into the sprint backlog. When the size of the sprint backlog is equal to the previous sprint's velocity (or the estimated velocity for the first sprint, since you don't have ...


10

A user story represents something that provides value to the business. Is it valuable to your business to provide a working feature to your design team? If so, create a user story that says that: As a member of the design team, I want a working version of feature x so that I can create a final visual design that is appealing. Is there business value ...


10

As far as I know, there are no alternatives to user stories, intended in their original meaning of "placeholders for conversations that we need to have". Stories cannot be more than placeholders because The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. is one of the 12 ...


9

Ideally, documentation is part of every user story and never builds up. But, in the real world, that often doesn't happen. In that case, you should create a user story for catching up on a specific missing piece of documentation. You're right, it doesn't produce any code. But it does satisfy a user requirement and should be prioritised against other user ...



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