How do you avoid waiting for requirements when using iterative agile development methods like SCRUM? [closed]

Question

We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.

EDIT: Additional Information: We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.

EDIT: More insight/confusion perhaps: I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.

Guaco

Answer 1

Don't wait. Build a prototype based on whatever minimal requirements you do have and get feedback ASAP from the product owner. More often than not they don't know what they want anyway - if you can show them something tangible as a starting point you're more likely to get useful feedback. Also, once you have a better idea of the real requirements you will probably have already gained a lot of insight from developing your prototype.

Calvano

Answer 2

If I understand your situation correctly, the BAs are the ones falling behind. There are two things you could try.

1. Try either small sprints or smaller requirement chunks. Either way the work for the BAs should be more concise and managable.

2. Take an interation to rework or bug squash. That should give the BAs sometime to get ahead of the curve.

If, however, the problem is that the BAs need to see the previous requirements in the "wild" before making more requirements you have much bigger issues. :)

Mcnally

I'm beginning to wonder if there is a problem with our user stories in that they are too vague/set ahead of time. – Guaco

Answer 3

At a previous position we managed this by asking our business customers to be a week ahead or so. Sure this breaks from some of the strict interpretations of agile but it made things so much easier. We would have both testing and the business working a week or 2 off from development so when developers were working on iteration 2 testing is working on what came out of IT1 and the business is on IT3. Priority was always given to active development so sometimes it broke down if a story was particularly flexible (i.e. the business had to spend lots of time revising things mid iteration) but overall it worked well.

Update to respond to the questioneers Update

It seems to me those don't really stand on their own as stories then and maybe the BA team needs to reevaluate how they are writing stories. I mean you can't reall "tell a tale" with customize X screen. In theory a story should be something like "When the user goes to screen X they should be able to modify (and save) the floozit"

Oralle

Hmmm... the problem is the screen is already there... so the changes are along the lines of 'move this field over here' or 'this field need to be calculated like XXXXXXX instead of how it is now'. Our requirements docs that we get are basically a big list of these to change for the screen. – Guaco

Interesting. My first thought then would be why not make each of those items stories albiet very very low complexity stories. If that isnt feasable or simply a waste of time I'd go with what other people have said and ask the BAs to get those lists together earlier in the process. – Oralle

That's the problem. There is a big backlog of the BAs putting together this requirement documents. It gets brought up at every sprint review session. We ask for them to be done sooner, but they are working nonstop. – Guaco

On a side note... your named seemed familiar for some reason. I think I have determined that you are friends with Ben Lee, whom I worked with for a while in 2007. – Guaco

You are 100% correct he is an old college roomate of mine. – Oralle

Answer 4

Sounds like the BAs may not be handing you your user stories for the sprint in a timely manner.

I take it that there is no sprint planning sessions from what you say.

Given that one of the big tenets of Scrum is that the development team takes responsibility for what they will work on per sprint, it sounds like this ain't too agile to me! (-:

Apart from having short sprints that is.

Witless

Our business owner and scrum master come up with the list of things that we do for the sprint and then assign who does them. At our planning sessions we normally just provide the estimates, so they are not very useful. We used to volunteer for the tasks in the sprint planning too... not anymore tho – Guaco

Answer 5

Well, a couple of things might help - In the SCRUM process, there is the concept of Product Owner wchich is a Pig Role, this represents the customer. So you can invite the PLM or the client's main contact to your SCRUM's meeting. This will give your customer's some buy-in into your process and will get them to work "with" you on your goals - Weekly builds to the client might help. So, the basic idea of the weekly drops is to show the customer "progress". So if for a few weeks there is no progress, this should raise the question "why?" and then you should be able to explain that it is for the lack of requirements finalization.

Hope this helps

Optimism

Answer 6

the "user story" is a placeholder for a future conversation, so get in front of the customer and ask them; if that's the BA's job, light a fire ;-)

Arvind

Answer 7

Your user stories are incomplete. 'Customize X screen' is a task, it doesn't describe any requirements or completion criteria. The user story should be something like 'Allow Nancy to see the related purchase orders for an item in inventory'. Then break that down into tasks during your sprint that you can work on.

Once the BAs have developed a workable user story then add it to your product backlog, prioritize it, and plan your sprints for the top backlog items. The BAs should be developing user stories and adding to your backlog independent of your sprints, and thus not blocking you. During a sprint the tasks are completed and the user story does not change. After releasing the customer provides feedback which goes into the product backlog as more user stories.

Bryce

Answer 8

I see a few ways to handle this:

Option 1, Under SCRUM, you should have a Product Owner who is managing your product backlog, which is supposed to contain requests for features of the software. If the feature consists of something vague like 'Customize screen X' and you decide to add that to your sprint, then the sprint tasks should be concrete, decomposed tasks, and I would say one of those tasks has to be 'Define requirements for screen X'.

During the daily SCRUM, when you're asking your three questions of each team member, the developer who has that screen mod task will say "I'm blocked waiting for requirements from the BA.", and your scrum master does what they can to get that moving along.

option 2, in my opinion, is that items do not go into your product backlog until they're defined well enough to do at least some productive work on. We all know requirements change, but the point is that you're supposed to have enough to start with.

Stumble

Answer 9

Easy.

Allow yourself to think outside of Scrum's strict rules, and get back to your lean roots: http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/ http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/ http://www.infoq.com/articles/hiranabe-lean-agile-kanban

Trust me, once you get that flow going, you'll never look back.

Barefaced

Answer 10

As it is said above, usually at the beginning of each sprint you should prioritize the existing backlog and pick some stories for the current sprint. If there is not enough user stories for the developers, you should shift developers to another project and let the product owner some time to create a decent (=large enough to feed some team) backlog for the project.

Scyros