Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Agile/Scrum development is a very collaborative development process. e.g. it requires developers to continuously communicate & work closely together day-in day-out.
How do you handle your "off" days? Those days that you just don't have energy, can't think straight, don't really have anything to say at the standup meetings, etc.
Just like how athletes have their off days.
I don't think there should really be a day where you don't have anything to say at the standup meeting. Every standup meeting should be used to let the rest of the team know whether or not you met the prior day's commitments.
One problem that I have seen on a lot of agile teams is that the developers don't make concrete commitments on a daily basis, so the daily stand-ups aren't all that effective. If that is an issue, make sure everyone in attendance is setting out concrete goals on a daily basis that can objectively be communicated the next day as either done or not done.
To the rest of your question, I think it is perfectly acceptable to go into a daily stand-up and say that you didn't meet the prior day's objective because you had an off day and use the meeting as an opportunity to make new commitments. If there was a reason why you had an off day that could be clearly identified as an impediment (e.g. too many interruption, unclear requirements/objectives, dev environment frustrations), those reasons should be reported to the whomever is leading the stand-ups (scrum master) because it is their responsibility to make sure those impediments are addressed.
If you don't get anything done, say you couldn't focus and didn't get anything done at the standup meeting. The Scrum Master should try to find out of there is some factor that's distracting you, and try to remove it for you.
Also, if these "off days" are semi-frequent occurrences, try to figure out how often they occur, and include them in your estimates. Scrum is about what's really going on. It's about real timelines. If you know you have 4 off days in 4 weeks, then you should only be claiming 4 days a week worth of work, not 5. (That being said, it's possible that what you can do in 4 days is the same as what someone else can do in 5 days).
Pair programming makes it easier to handle. At least with pair programming, somebody else is there to catch your mistakes early.
Pick a different task/story to work on - so that you get a change on scene. Maybe you've been on the same user story too long.
Gold Cards - (or "fedex days") - where you can work on anything you want: http://www.planningcards.com/iterex/papers/InnovationAndSustainabilityWithGoldCards.pdf What's noticeable about "gold cards" is that the team that introduced them found that they didn't cause a drop in productivity. This would suggest that it's better to take somebody out of the process on an off day and let them do something constructive of their own choosing than let them work unproductively.
Depends if you're running the meetings, many people opt for the "Daily Scrum" whilst working on projects, but often they are time wasters and unnecessary. Structure your meetings around when things are completed, if you're completing and re-assigning tasks everyday, then yes, a daily meeting is a good thing, but realistically you can schedule and discuss a number of tasks in one meeting and then re-visit later in the week. Ideally the most efficient meetings usually consist of one weekly meeting (Monday) and quick progress catch up (Wednesday - Thursday). If you're the project manager, insist that team members respond to you directly when they complete work before the next meeting takes place. If you're holding official daily meetings, you're likely burn out with in a month! (and so are your staff). If you have to do daily meetings, make them quick catch ups, set at the same time everyday and only offer the most relevant information and only have one proper meeting during the week. If you'd like to know what to do on your "off days", I can only suggest that you cancel the meeting, take a Berocca, walk around the block, complete your filing and actually do some work instead of holding relentless meetings for a change.
G'day,
As mkedobbs mentioned, you should mention it in the stand-up meeting.
Maybe you need to look at what's making you have an "off" day and communicate that with your team members.
Is it due to you banging your head against a problem and you're losing motivation? Mentioning it in the stand-up may reveal another team member who has previously come up against the problem. They have maybe even solved it, or their experiences and observations may be slightly different to yours but the combination of two heads may solve the issue for both of you.
Is it due to your user story turning out to be much bigger than expected and you're feeling overwhelmed? Raising the issue in the stand-up will help resolve the problem. Maybe this particular user story should be considered a user theme or even a user epic and needs to be broken down into several user stories.
Is it because the user story you finished up with is not what you normally do? Discussing this in the stand-up may uncover team members that do have experience in the particular area covered by the user story. And those team members may be able to provide pointers to help you, maybe directly with the work itself, or with some other resources to help you come up to speed.
These are just a few reasons as to why your "off" day may be directly due to your current work. But definitely don't just stay silent though! Mention it at the stand-up so that any potential problems may be addressed sooner rather than later.
HTH
cheers,
I have off days. My team has off days.
If it is happening a lot or if it is the same people, then root cause and action is needed. This might be a good topic for a retrospective if the whole team is affected or one-on-one if it is an individual.
As for the answer, you are part of a team. The team picks up the effort, just like any other issue. If you team has issues with this, you probably don't have a well formed team and just have a bunch of individuals fending for themselves.
Generally at the start of an "off" day, it isn't clear that the day will go badly. It is only after a few stumbles that it becomes clear that it isn't going to be a good day. I'd still try to get something done but sometimes the progress is minuscule. The following day's stand-up is when to say, "Yesterday, I didn't get much done. I had an off day," or something similar to note that I do recognize that things didn't go well and I'd try to do better today.
Sometimes I'd change what I'm doing that day, as that can sometimes help. I have had times where I get a few off days in a row, which generally is indicative of needing to take a personal or vacation day and try to recharge myself to get back in the saddle again.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Specifically, should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it? Thanks!
We use the time to fix bugs, and to pay back some technical debt.
If you can do this without talking to your product owner depends on your understanding of scrum or your work arrangement with the product owner.
In my personal opinion you make a promise for the sprint. Your part of the deal is to hold the promise. The Product Owner on the other hand is supposed to stay out of technical stuff, since that's what the developers are good at. Technical Debt is technical stuff. Bugs might be. But in the end you have to come to a common understanding with the PO what you can decide on your own and what you have to consult the PO with. In an ideal world the developers know so much about the product that they can make the decision on their own.
Starting on the next item is of course another option. If you can't finish it, Lex Scrum says don't touch it. And I like this law to some extend, because it actually creates slack that can be put to good use by developers ... like fixing bugs and paying back technical debt. If implementing another story is the best use of your time: find one that you can finish. If you can't find/create one, this is actually an impediment that you just found. Assuming we are talking at least about something like 4hours for 2-3 developers, we really should be able to find something useful to implement with these resources, shouldn't we?
should you only accept new work you know the team can finish in the given iteration? Is it ok to start the next highest priority backlog item even if you know the team doesn't have time to finish it?
Remember "Individuals and interactions over processes and tools" Do what your common sense tells you. Do not get too caught up in tools and processes.
As per the Scrum guide, the amount of work the Team commits to is completely up to the Team.
There is no harm in starting a next highest priority item when all the items above it are done. What would be preferable though is break the item down into a smaller or thinner slice which can actually be done.
If the Team finishes all it's Backlog Items well ahead of time, the team should definitely take up a few more.
I would take the next highest item in the backlog and work with the product owner on creating a story that can can be completed in this iteration...so break the story into a smaller size to fit.
We haven't taken new work irrespective of whether it can be finished within the sprint or not. You should instead focus on Technical Debt, Design Debt, Code Debt
Definitely break the story into something that fits. The team should never be committing to something it can't finish in a sprint. Additionally, only the team can add new work. If the team finishes early, the team needs to work with the Product Owner and agree to add work to the sprint. I've seen teams get into trouble when the "lead" or even the Scrummaster starts negotiating with the Product Owner outside of the team.
To answer the question definitively, Scrum says that you should negotiate with the Product Owner and about taking in extra work.
Scrum done well has the Scrum Team review their progress every day so you should see an early finish predicted way before it actually happens, giving you enough time to chat with the Product Owner about what to bring in to the Sprint.
Scrum done well also has the Scrum Team prepare User Stories well in advance of being pulled in to a Sprint (via Sprint Planning and Product Backlog Refinement) so the need to break a User Story into smaller components so they can fit in to a Sprint is lessened considerably.
Either you can break a story into a smaller one so you can deal with it within the current sprint or you can have a story informally split into two sprints putting off some of its tasks to the next one.
Remember that agile comes down to finding the best way to fit your team's needs, not about following structured rules.
Whichever way you go, I'd simply go to the team and ask them what do they want or think they should do. Remember, in Scrum we value self managing teams.
For suggestions, if they're stumped, I would say do one of the following:
Reduce technical debt
Use the time to learn something valuable
Let the team take a "Gold Card". They're on time, they probably earned it.
Split the next story into smaller (though still meaningful) stories, the first of which can be completed in time for the end of the sprint.
If the next story can't be completed as above, take the next story that can be completed in time.
Hope this helps,
Assaf.
Here's what my teams do-
First, it's up to the team to decide what additional work that they can fit into the remaining part of the sprint. It's critical that the whole team votes on this, not just the developers.
Second, if the team decides that they can handle X more points of work then they go to the PO and confirm the priority of the backlog items and find one or more stories that sum up to that X points. Sometimes they have to move down the backlog a bit to find ones that will fit. As long as the PO is ok with the final selection, the team moves forward with the new work.
Third, whatever new work the team selects has the same commitment level as the original work. Any partially completed stories at the end of the sprint are failed.
Finally, during planning for the next sprint, the velocity is adjusted upward (in this case) because it's quite likely that the team under-selected work at the beginning. This is a crucial point - the velocity should always reflect the team's best guess based on recent past history as to their work capacity. If the PO sees that the team is finishing early and heading off to do other non-backlog work, this can cause trust problems between the PO and the team. It's perfectly fine to decide as a team along with the PO to focus on technical debt (although I think that these are still stories since the work needs to be tested) or other items as long as there is discussion and agreement.
I think this is something you'll need to take a view on after a number of sprints. If you're regularly left with spare time at the end of a sprint, you should probably commit to more work in the planning session.
If it is happening rarely, I'd caution against routinely adding in tasks from the backlog as a matter of course. Unless you've done some decent backlog grooming they're unlikely to be the quick-wins they first appear. You also want to avoid a protracted mini planning session as those days you have free could quickly trickle away - especially if you're including the views of developers who have tasks outstanding.
By all means, seek to get ahead for the next sprint by reducing technical debt or backlog grooming etc but putting yourself on the back foot by committing to work late on is rarely worth the effort.
I think a solution of an under-committed sprint could be to stop the sprint. If the team has done the work then the sprint is over. The other option of adding more stories into the sprint backlog is too risky, and rarely will a team be 100% sure they can handle all the extra work.
As far as I know there is no rule that a (let's say, 2-week) sprint cannot be ended 2 or 3 days early.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We've been recently implementing Scrum and one of the things we often wonder is the granularity of tasks within stories.
A few people inside our company state that ideally those tasks should be very finely grained, that is, every little part that contributes to delivering a story should represent a task. They argument that this enables tracking on how we are performing in the current sprint.
That leads to a high number of tasks detailing many technical aspects and small actions that need to be done such as create a DAO for component X to persist in database.
I've also been reading Ken Schwaber and Mike Beedle's book, Agile Software Development with Scrum, and I've taken the understanding that tasks should really have this kind of granularity; in one of the chapters, they state that tasks should take between 4 to 16 hours to complete.
What I've noticed though, is that with such small tasks we often tend do overspecify things and when our solution differs from what we've previously established in our planning meetings we need to create many new tasks or replace the old ones. Team members also refrain from having to track each and every
thing they are doing inside the sprint and creating new tasks since that means we'll have to increment our total tasks in our burndown chart but not necessarily adding a task that aggregates value.
So, ideally, how granular should tasks be inside each story?
Schwaber and Beedle say "roughly four to sixteen hours."
The upper bound is useful. It forces the team to plan, and helps provide daily visibility of progress.
The lower bound is a useful target for most tasks, to avoid the fragility and costs of overspecification. However, occasionally the team may find shorter tasks useful in planning, and is free to include those. There should be no mandated lower bound.
For example, one of our current stories includes a task to send something to another team -- a task that will take 0 hours, but one we want to remember to finish.
The number of tasks in your burndown chart is irrelevant. It's the remaining time that matters. The team should feel free to change the tasks during the sprint, as Schwaber and Beedle note.
On my last assignment we had between 4 and 32 hours per task. We discovered that when we estimated tasks to more than ~32 hours it was because we did not understand what and how to do the task during estimation.
The effect was that the actual implementation time of those tasks varied much more than smaller task. We often also got "stuck" on those tasks or picked the wrong path or had misunderstood the requirements.
Later we learned that when estimated tasks to be that long it was a signal to try to break it down more. If that was not possible we rejected the task and sent it back for further investigation.
Edit
It also gives a nice feeling to complete tasks at least a couple of times a week.
It also gives rather fast feedback when something does not go as planned. If someone did not complete an 8h task in two days we discussed if the person was stuck on some part, if somebody else had some ideas how to progress or if the estimate was simply wrong from the beginning.
Tasks should probably take one-half day to a day, maybe as much as two days sometimes.
Think about it this way: on a more macro level, short iterations promote agility by creating small amounts of value quickly and allowing plans to change as business needs change. On a more micro level, the same is true for tasks. Just like you don't want to spend 3 months on a single iteration, you don't want to spend a week on a single task.
Daily standup meetings can give you a clue that your task size is too big. If team members frequently answer "What did you do yesterday?" and "What will you do today?" with the same answer that they gave the day before, your tasks are probably not small enough.
An example of that would be if a team member regularly answers: "I worked on BigComplexFeatureObject today and will work on it tomorrow" for more than one day in a row, that's a clue that your tasks may be too big. Hopefully, the majority of days a team member will report having completed one task and be about to start another.
Short tasks, 4-16 hours as others have said, also give the PO and team good feedback about project progress. And they prevent team members from going down "rabbit trails" and spending a lot of effort on work that might not be needed if business desires change.
A nice thing about having many smaller tasks is that it potentially gives the PO room to prioritize tasks better and optimize delivered value. You'd be surprised how many "important" parts of big tasks can be postponed or eliminated if they are their own small task.
Generally a good yardstick is that a task is something you do on a given day. This is ideal, which means it's rare. But it does fit nicely into that 4-16 hour estimate (some take half a day, some take two days, etc.) that you gave. Granted, I don't think I've ever spent an entire uninterrupted day on a single task. At the very least, you have to break for the scrum meeting. (At a previous job a day of coding was considered 6 hours to account for overhead.)
I can understand the temptation of management to want to plan every single granular detail. That way they can micro-manage every aspect of it. But in practice that just doesn't work. They may also think that they can then use the task descriptions to somehow generate detailed documentation about the software, essentially skipping that as an actual task itself. Again, doesn't work in reality.
Agile development does call for small work items, but taking it too far defeats the purpose entirely. It ends up becoming a problem of too much up-front planning and having to put in a ton of extra re-planning any time anything changes. At that point it's no longer agile, it's just a series of smaller waterfalls.
I don't think that there is a universal answer to this question that fits every situation. I think that you should try what your collegues are proposing, and after the first sprint or two you evaluate and see if the process needs tweaking to accomodate everyones needs and wishes.
That 4 hour figure sounds like a good minimum to me. I like to think in terms of visible results. We don't have a task per line of code, or a label on a screen, or per refactored utility method surely? But when we get to something that someone else can use, like a public class used by someone else, or a set of fields on a screen that allow some useful action then this sounds like a trackable task to me.
For me the key question is "Do we know we've finished it?" with individual helper functions there's a pretty good chance of refactoring and change, but when I say to my colleage "Here, use this" it either works or it doesn't. The task's completeness can be evaluated.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Scrum and agile says that items on the current sprint backlog should be approached in priority order, and one item at a time by the whole team.
Practically, that never seems to work for our team. Either the item is too small for all team members to be productive (including taking pairing into account). So we end up perhaps doing two or three items across the team at any one time.
I'd be interested to hear how other teams do it, and also how many items they usually commit to in a given sprint.
items on the current sprint backlog should be approached in priority order, and one item at a time by the whole team.
I don't know who says this, I at least don't remember having heard or read anything like the emphasized text so far. Of course, it depends also on whether an item for you is a story or a single task.
If it's a story (usually consisting of several tasks), there might be a chance of achieving this. However, as you say, sometimes the story just doesn't include enough tasks to keep everyone busy. Also often the tasks related to a story strongly depend on each other, e.g. there might be a design session (involving part or whole of team), then one or more coding tasks, then code review, functional testing, documentation etc. Obviously one can't do functional testing before the coding, and so on.
Since everyone has to do something, there will be at least as many tasks open at any given time as there are team members (or pairs). Taking into account that sometimes tasks are on hold for various reasons (inter-task dependencies, information needed from external parties etc.), usually even more.
In one Scrum project with a team of 4 developers, we had a very similar situation. We did strive to take stories in priority order as much as possible, and usually we had multiple stories and several tasks open at any time. In the beginning we often had problems with several half-finished stories at the end of the sprint. So we realized it is important to keep the number of open tasks / stories to a minimum, i.e. always attempt to finish open tasks /stories first before starting a new one. But practically, that minimum was never meant to be 1.
As for the number of stories per sprint, we just put in as many as we could comfortably fit in based on our (story, then task level) estimations. That was of course greatly influenced by our velocity, which in the beginning was estimated too high. After a couple of months we chipped it down to 60%, and that value seemed to work for us.
The advice to approach each item by the whole team is there to avoid creating mini-waterfalls within sprints, where items are passed from one specialized group to another. That leads to stuff like testers having nothing to do in first days of the sprint, then working overtime for the last couple of days when coders fiddle their thumbs. Teams should approach the problem as a whole with everyone chipping in, even outside of their respective "specialization". Yes, coders can test, testers can code and both can design architectures etc. - and in the process learn something new (amazing). That is not to say everyone should be very good at everything - it is just to say attitude like "I don't test, I'm a coder" or "I won't write this script, I'm a tester" should have no place in a Scrum team.
It is also advised to tackle items one by one inside of sprint to make sure something is actually delivered at the end. Limiting work in progress (WIP) prevents situation, where everyone did some tasks on each item, but no item has been completed by sprint's end.
However, this shouldn't be viewed as advice, not a very strict rule. For example when you have two small stories and a team of 10 it probably doesn't make sense to have all of the team swarm on just one story.
Bottom line is: no one should tell the team how to divide work among themselves, but delivering what they committed to at Sprint Planning should be expected.
I think it depends on the makeup of your team. If you have a team where anyone can take on any given task within a user story, then this works well. If you do not, then there will likely be idle time for some individuals.
The point in working the user stories based on priority is simple... you get the highest priority user story completed first. This adds the most value from the perspective of the customer who actually set the priority.
As for how many user stories to commit to during a sprint, that depends on a few factors:
Team Availability, Team Velocity, and Sprint Duration. So, I'm not sure how much value you will get out of knowing how many stories other people tackle during a sprint.
Noel, is your team trained to work in a Scrum team ? I mean did you send them to Scrum Course prior beginning the project ?
I've seen so many team failing with Scrum just because they misunderstood what was written in a book on a blog.
Also having an experienced Scrum Practitioner or Scrum Coach will help you a lot.
To answer your question specifically, check this nice free ebook that is different than others:
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So I have a backlog of features and we are about to get started on a sizable project. I am working on defining the structure of our sprints and I'm interested in the communities feedback.
What I'm thinking is:
One day sprint planning
Fill the backlog and figure out what each dev will go after this sprint
Three weeks of development
GO! GO! GO!
Daily stand up meeting
Check to see if anyone needs help or feels off track
Two days of sprint review
code reviews happen here, stakeholder presentations
One day sprint retrospective
what did we get done in the last sprint? how can we do better next time?
Sprints should always end on a Tuesday (to avoid too much weekend stress).
Anything else? There is obviously more to agile than this. I want to provide the team with a simple outline of how we are going to operate as we get this project started.
I'd consider experimenting with sprints that are shorter then one month.
Personally I find one-two week iterations more effective at getting effective feedback quickly. It also prevents any issues that may be causing problems at the iteration level building up to levels that become harder to manage.
Even for the 30 day sprint - two days sounds about a day to long for the sprint review... and one day sounds about 0.5 days too long for the retrospective. I've found that if you need much more than that there have been communication problems while the iterations has been going on - so you might want to look at needing long reviews as a possible red flag.
Of course that's just been my experience - of mostly developing web apps with smallish (4-12) person teams. You're experience may vary.
That said - I'd definitely give shorter sprints a try. Like integration builds - a lot of things get easier if you do them more often.
Turn off email, cell phone and instant messaging apps for core code time. 10am to 1pm, 2pm to 5pm might be good blocks for this.
Order food, drinks for team when they are in "the zone".
Cancel all other meetings for the days of, before and after the planning session and the review days.
Make sure the "stand-up" remains a STAND-up. It is very easy to slide into longer and longer meetings.
One day of sprint planning and three days at the end may be too much. Only schedule as much time as you need.
+1 to the idea of shorter iterations. Personally, four one-week iterations within a sprint have worked well. People are great at estimating near-term tasks; past that it becomes more and more guesswork.
Looks like a good approach. I second what adrianh and jedidja said about possibly shorter iterations. I like 1 weekers myself. As well as better estimation, it also keeps the idea of "working software" on a much shorter cycle.
A few questions:
Why are code reviews left until the end? Either pair program, or do your reviews as you go.
Does 3 weeks of development mean "dev, test, documentation, installers, etc" ? I.e. everything you need to be truly done?
We structure our sprints very similar to your outline except our sprint reviews are the last day of the sprint and generally on last about an hour. The sprint review is the time where you exhibit your work to the customers and any other interested parties, not the time to do code reviews. Code reviews, if you chose to do them, should be done periodically throughout the sprint. We used to have a one hour block each week where we'd go over developer nominated code, meaning we didn't waste time reviewing every LOC written.
We also end our sprints on a Tuesday and begin on a Thursday leaving Wednesday to wrap up loose ends and tackle technical debt created during the sprint.
I don't recommend postponing code reviews until after the sprint, they should be an integral part of the development process. In other words, a task is not done unless the code has been reviewed (and tested, and documented, and ...).
Its important to stay away from managing for the sake of managing. SCRUM only requires 1 meeting a day, and that's a short one. Additionally, during each sprint, the only other meetings are the Spring retrospective, and the sprint planning. This allows us to implement ROWE, or a Results Oriented Work Environment. Let your developers decide How, Where, When they will do thier development. Use your daily stand-ups to track that they are doing their work. Other than that, stand back and be amazed at thier productivity.
Ideas like "turn off cell phones, turn off IM apps, etc during coding" are all bad ideas. When you hire your team, you are hiring them with confidence that they know how to do thier job correctly. If you hired them with that understanding, why would you want to constrain thier ability to get thier job done the best way they know possible? If you're using SCRUM, then each developer will have chosen the work they feel they're able to do, your job as a Scrum-Master is to remove obstacles, not create them.
Code Reviews: Absolutely necessary. Peer reviews of code are a great teaching tool for junior developers attending meetings, and for the folks having thier code reviewed.
Design Documents: I personally feel that detailed design documents covering what the developer intends to do is very important, and I also feel they are an important part of the development process. Now, this is not specifically in-line with agile development, but I personally regularly refer back to design documents created years ago to see what the original developer was thinking when they coded their modules.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this 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.
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.
If I understand your situation correctly, the BAs are the ones falling behind. There are two things you could try.
Try either small sprints or smaller requirement chunks. Either way the work for the BAs should be more concise and managable.
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. :)
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"
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.
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
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 ;-)
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.
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.
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.
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.