Tag Info

Hot answers tagged

24

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


23

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


22

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


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


13

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

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


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

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


11

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


11

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

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


10

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


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

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


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


9

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


9

I am in favor of locking down stories fairly quickly in their life cycle. Requirements should be set after less than a day's worth of discussion in most cases. After that point, it's up to the product owner to decide if those requirements are actually something they want. If they aren't, cancel the story. If they are something they want or partly what they ...


9

I don't think the problem here is Scrum as such, I think the problem is that there isn't a clearly defined project deliverable and (I've experienced this many times) no clear direction. I think your technical tasks are fine, possibly on the large side but measurable and definable so absolutely fine for a story. Research tasks are a huge red flag for me in ...


9

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


9

What you are mentioning is a classic problem that many companies have introducing agile development. Unfortunately, there's no easy solution. For the specific problem of acceptance, the "standard" workaround is having someone in the team acting as a proxy for the product owner. This is not great but it can work as long as this person takes care to demo ...


8

When estimating, longer tasks have more room for variability. Variability means a lot of things - someone gets sick and takes a day off, someone gets pulled into meetings, someone has to support another project, you need to timeshare resources with other people or teams...the list goes on. By reducing the timeframe for a given task, you are trying to reduce ...


8

I feel like I say this a lot. Agile does not mean you need to put blinders on to ignore the future and design yourselves into a corner. Agile is about how you deliver functionality, and has very little to do with how you design functionality. In other words, it's okay to look as far into the future as you want when creating your design, as long as it ...


8

TL;DR Scrum does not mandate the use of user stories; they are simply a useful agile practice. While the Product Owner could certainly use technical specifications instead of user stories to build the Product Backlog, most of your other process problems stem from a failure to embrace effective Scrum and agile practices. Various Problems with Your Process ...


7

Agile follows several principles. One of them is: Empower people. Because of that tasks should be defined by team and tasks should be selected by team members. Tasks should not be assigned to team member. The team should be self organizing and because of that distribution of hard / easy / interesting / boring tasks should be even. Scrum master should ensure ...


7

Productivity is influenced by a number of factors - organizational culture, experience with the language and tools, knowledge of the project, specifics of the process being used, outside factors such as regulations, and capabilties of the team as a cohesive unit. This is why, when estimating projects, the most useful data is that of the specific team that ...



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