Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Good afternoon,

My work environment has some problems. Our IT team is trying to be more agile, but we're not really getting buy-in from the business. They attend our daily stand-ups and sprint reviews, and they help with sprint planning, but then they turn around and do 4 months of requirements gathering for a project before moving forward with a (mostly) serial development style. The sprint goals are things like "get XX% closer to release".

For the IT team, they've turned the Sprints into a sort of death march. We end a Sprint one day and start a new Sprint the very next day. There's no reflection or changes done between sprints, only during.

Having never done any of the agile methodologies before, I haven't had a very pleasant introduction to them. So my questions are:

1) Should there be some time (perhaps a week or so) between sprints to do the reflection/introspection/changes/etc.? Or are back-to-back-to-back sprints the norm?

2) Is there any chance for survival for an agile team with no agile business counter-parts? If not, are there some transitional methodologies or even tips for moving the business towards an iterative if not necessarily agile mindset?

3) Should your entire team be on every sprint? We have almost 20 programmers on a single sprint but working on completely different projects (typically teams of 3-5, sometimes larger). Is it normal to have a single sprint or should we be trying to manage multiple independent sprints? Should we be trying to keep the multiple sprints in concurrent lockstep or should their timetables be allowed to overlap and be flexible?

Any thoughts or advice is appreciated. This is my first time coming over from SO for a question, so please let me know if there are better ways to phrase these kinds of questions (faq was rather helpful, but still not sure I'm following it perfectly). Thanks!

share|improve this question

closed as too broad by Ixrec, GlenH7, durron597, MichaelT, Snowman May 28 '15 at 0:29

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

I hate the word "sprint" here. A sprint is an unsustainable effort. You run really fast, then you recover and let your body catch up with the energy expenditure and waste product buildup. Software projects are more like marathons, and a marathon is not 400+ hundred-meter sprints back to back. – David Thornley Feb 16 '11 at 20:21
up vote 5 down vote accepted

1) Usually you can just review the last sprint in one meeting, plan the next and begin it. Particularly review how accurate task estimates were and feed this into estimates for the next sprint. You could delay the next sprint if you need to wait for customer feedback from the results of the previous one and you think that feedback will influence the tasks for the next sprint.

2) It won't make it easier, but the team can of course succeed. Your comment

The sprint goals are things like "get XX% closer to release"

is a bit worrying as ideally you want to be including demonstrable features/functionality as the goals in a sprint.

3) You say there are 3-5 completely different project. If they are unrelated i.e. for different products, there is no need to have them in sync, but they should each be treated as independent sprints. It sounds like your teams for each sprint are probably a fine size.

share|improve this answer
+1: "get XX% closer to release" means you're not prioritizing or decomposing the requirements in any useful way. The "problem" is not the business. It's your team's response to the business. A big blob of requirements is something your team decomposes. Or it's not really Agile. – S.Lott Feb 16 '11 at 20:09
+1 for S. Lott's comment above. Decomposing the documents that come "over the wall" from a four month process in to user stories is a crucial part of how this works. – Kyle Hodgson May 29 '12 at 20:52

1) Should there be some time (perhaps a week or so) between sprints to do the reflection/introspection/changes/etc.?

No. A week? You must be crazy. 2 hours is the limit.

Or are back-to-back-to-back sprints the norm?

Absolutely. Otherwise, you're spinning your wheels.

Is there any chance for survival for an agile team with no agile business counter-parts?

Business is never "Agile". Agile is something you do. Not them. Indeed, never them. They just ask for random stuff. You manage it.

If not, are there some transitional methodologies or even tips for moving the business towards an iterative if not necessarily agile mindset?

None. You decompose the requirements into sprints. It's your discipline. Not theirs.

Should your entire team be on every sprint?


We have almost 20 programmers on a single sprint but working on completely different projects (typically teams of 3-5, sometimes larger).

What? That's not a team. That's a bunch of teams. 4 or maybe 5 separate teams.

Is it normal to have a single sprint or should we be trying to manage multiple independent sprints?

No idea what you're talking about. But, since you seem to have 4 or 5 teams all mashed together, it's clear that you're going to have massive confusion.

Should we be trying to keep the multiple sprints in concurrent lockstep or should their timetables be allowed to overlap and be flexible?

Each team -- and the team's sprints -- are the team's problem. No one else's.

Some folks things that big projects like this should be a "Scrum of Scrums". Teams set their goals, build their things. Representatives from each team get together periodically to coordinate the teams to get to mutually beneficial releases.

share|improve this answer

I'm sorry that you are in such an obviously dysfunctional organization.

If you wish to have any ability to measure progress, it is absolutely imperative that you plan in terms of 100% complete milestones. If there is ever any room for honest disagreement about what a particular milestone is, the natural tendency is for the person doing the work to take the most optimistic possible interpretation on how much they have done, and the person hearing what they say to hear that in the most optimistic possible ways. This means that the news gets better and better as you go up the chain, leading to a complete disconnect between reality and what the top hears. is a humorous, and entirely realistic take on this phenomena.

How bad is this disconnect? Consider this. In the average project, the actual time taken to completion (if you ever get there) averages double the original estimates. But no matter how much the project is delayed by, typically the people at the top don't get the first hints that the project is behind until about 2 weeks before the due date, as that is the point at which the disconnect between expectations and reality can no longer be hidden.

Therefore the XX% closer goals are not actual requirements. Literally your team should refuse to accept those as actual requirements. It is your job to educate them that you need concrete, actionable tasks, and in planning they will need to be broken down into specific tasks that can be estimated as taking at most a few hours.

Secondly, as others have said, you absolutely need to break down your team into smaller units, which probably will need to be on different schedules. Research indicates that a single software team of 20 people working on one thing can accomplish about as much as a team of 5-8 people. (I ran across this surprising fact in Steve McConnell's excellent book Software Estimation.)

Thirdly it is a really big red flag that it feels like a death march. If it feels like a death march, it probably is a death march. Software developers tend to be at peak performance when they are working 35-40 hours a week. (I got that figure from Steve McConnell's Rapid Development.) Working longer hours can get temporary performance increases, at the cost of long-term reduction in performance. A large project is a marathon, you need to pace yourself.

Fourth there really needs to be a rhythm to a sprint. When I worked in a team doing scrum, we found it very useful to divide each sprint into two sections that we called "long focus" and "short focus". During "long focus" we did heads down software development on the tasks that had been agreed on for that sprint. During "short focus" we did all of the necessary stuff we needed to that involves lots of interruptions and task switching. So that was when we did QA, bug fixing, various meetings, estimating tasks for the next sprint, and finally agreed on what would and wouldn't be in the next sprint. This worked very well for us because a lot of software development can only be done when you are in the "zone", which generally doesn't start until you have been doing one task for at least 15 minutes with no interruptions.

If you follow a rhythm like that then you get another win out of having different schedules between teams: your QA people can always work on whatever team is currently in QA, which keeps them with a constant level of work.

Good luck, and be aware that without support from the top you may be unable to fix the dysfunction. If that is the case then your best realistic option may be to find a healthier organization to be part of rather than trying to make your organization into something that it is not going to become.

share|improve this answer
  1. My experience is that sprints are generally back to back with some loss of time to do retrospectives, demonstrate functionality, and plan the next sprint. For example, the last day of a sprint would often be considered a write-off as there would be 3 meetings that spanned that day typically so a 2 week sprint equaled 9 working days. The retrospective at the end of a sprint can bring changes to be tried in the next sprint that starts almost immediately in a sense.

  2. A chance yes but rather small as if you use Scrum there should be a product owner that is approved by management to direct prioritization of how urgently are some stories compared to others. There has to be some understanding of what responsibility they have though another part is that the "XX% closer to release" is a rather poor metric to my mind as this tends to not include bugs and other last minute issues that are nearly impossible to properly estimate in my limited experience. There is also something to be said for understanding when changes to priorities can be known to the team and used in planning a sprint. Management buy-in is crucial as if they don't understand what you are doing it may be like trying to make deliveries while walking on a stationary tread mill. While your legs are moving, you aren't getting any closer to dropping off anything.

  3. Not necessarily but sometimes that can be the case. The key is to know how much is each developer allocated to the project and keeping this consistent so that when there is a velocity from the first few initial sprints, this is useful in predicting future velocities rather than being useless as the number of man hours on the projects bounces around too much to easier estimate how many points can be done in a sprint. Each project should have its own set of sprints if the project is big enough to span into weeks of work.

Good luck on educating management in terms of what they have to do and how this works as that may be your big hurdle to overcome here.

share|improve this answer
Thanks for answering. We're not doing user stories yet (our requirements documentation is abysmal) but I've already started that fight and I've found plenty of resources for how to encourage their use and get away from the "##% closer to production" metric. These were questions I was having trouble finding answers to elsewhere on the web. – Riggy Feb 16 '11 at 18:39
The first 90% of the job takes 90% of the work. The last 10% takes the remaining 90%. – btilly Feb 16 '11 at 20:57

If your project is utilizing Scrum, then you should have a Scrummaster whose job it is to educate all parties on how exactly the process is supposed to work. If you are doing Scrum, sounds like the scrummaster is not doing his/her job, since having no buyoff from the business side of the project is a HUGE (and not uncommon) roadblock.

share|improve this answer

Tell the program people to screw it if they say get XX% closer to complete. TELL them you will finish requirent X, Y and Z by such and such a date. If they want to contract the schedule ask them what they want to remove, if they balk tell them they either remove pieces or add time. Saying get it done or else won't do a bit of good. If they push assign your project manager code to complete that sprint. Bear in mind Agile is a team effort. If the project management people aren't working 12 hours days they better like hell be there fetching pizza and sodas for the people that are and any bonus for getting things done on or ahead of schedule better go to the people that did the work too. Tell upper mgmt if you have too, they are probably the ones that pushed Agile on you while not training the project management people.

Track your progress, make adjustments then pick the next requirements to meet. If the project isn't going to be delivered until the whole thing is done, don't worry about priority of features, worry about what features are important to you that they be done for future pieces. You have to take ownership of this. It should not be a death march either. Scrum projects should be measuring the amount of work you can complete in the duration of a NORMAL sprint. That 10 (or 9 as noted above) normal 8 hour working days.

One thing I heard at the Agile conference a few years ago was that your team is like a factory and it can product X amount of cars (or in your case features) per sprint.

Also your sprint teams should be 3 to 5 people not 20. That could be part of the issue. Each team should be picking their stories (requirements line items if you like) and working to those. They should scrum separately, but meet large group on some basis to share ideas.

When managing these types of teams it may be better for the managers to scrum separately to determine what cross team tasks are needed and put the right people in touch. A 20 person standup is monotonous and boring for those involved.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.