Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In my organization Scrum teams almost never finish all of their stories 100%. I suggested that we commit to fewer stories each Sprint, but the R&D manager says if we do that people will still not complete the work, but will just do less of it thus slowing down development. He says there is a Student Syndrome at work here.

What is your take on that?

share|improve this question
    
What's a Student Syndrome? They give up and wait for the teacher to give them the answer? –  JeffO Feb 11 at 11:20
    
@JeffO Student Syndrome is the name for when people look at a task, determine how long they think it will take (or how long they are told they have to work on it), and then begin working on it at the last possible minute to complete it on time. In project scheduling, this is problematic if there are buffers built into the schedule to account for problems that may arise in the task. –  Thomas Owens Feb 11 at 11:24
    
See also Parkinson's Law. en.wikipedia.org/wiki/Parkinson's_law –  pdr Feb 11 at 11:26
    
Are they missing stories on every sprint? –  JeffO Feb 11 at 11:28
    
Most Sprints they miss a story entirely, but in all Sprints they don't do all the stories 100%. –  Eugene Feb 11 at 13:04
show 2 more comments

3 Answers

up vote 16 down vote accepted

Your manager needs to understand that Student Syndrome / Parkinson's Law becomes a significantly larger problem when there is zero hope of hitting targets. Suddenly the time available for a task's completion is infinite. As an old colleague of mine used to put it, "Deadlines are just things that pass by here. We miss them, they get moved back, we miss them again."

And that was entirely a result of unreasonable deadlines in the first place. These people weren't naturally lazy, they just saw no hope of hitting a target and no consequence of not hitting it, so why worry about it?

My point being that your manager might well be right. But he needs to understand that he's creating the problem.

When a team does sprint planning well, they start working as a team to hit their deadlines. Any one person doesn't pull their weight, they fail as a team. If that happens continually, the team deals with that person.

There is a possibility that you will cut the velocity too much and achieve less than you might have. But you will have succeeded. Feelings in the team will be positive. Someone is likely to say "Honestly, I think we can achieve a couple more points next sprint."

Eventually, you'll find your balance point and start predicting correctly the amount of work you can actually achieve in an iteration.

share|improve this answer
add comment

Who cares? Shouldn't the produce owner be asking where's the rest of my features?

You may need to limit the length of your sprints. This way more progress has to be shown along with way. Use the feedback on what is getting done to determine how much can be accomplished in subsequent sprints.

You can't have a fixed timeframe for a project and a fixed list of stores/features without allocating enough resources. If there is a fixed due date, you may not get all the stories finished. You want to cut out some stories? Which ones? Can you really determine that at the beginning? Hopefully, if you prioritize right, the product owner gets what's most important. It's their priority after-all.

The manager is playing mind games. If you're a kid who wants a dog, ask for a pony.

share|improve this answer
add comment

In my organization Scrum teams almost never finish all of their stories 100%. I suggested that we commit to fewer stories each Sprint, but the R&D manager says if we do that people will still not complete the work, but will just do less of it thus slowing down development. He says there is a Student Syndrome at work here.

From my limited experience with [what poses for] Agile, I'm not surprised. Everything I've read about Agile suggests that everybody needs far more organised than in other development technique but, like you, I'm seeing little, if any, evidence of it.

Estimating Story Points is not an exact science, especially in "cutting-edge" areas like R&D. It could easily be that your Developers are mis-estimating their Story Points (IME, usually over-estimating their own abilities) or it might be that there's some "target" number of Points that they're supposed to produce in each Sprint (IMHO, an utterly flawed way to manage, which brings me to ...).

Your manager needs to be investigating this and finding out what's not working. It's their responsibility to get stuff delivered to the clients (or it ought to be), and so their "neck on the block" when the users start complaining.
[cynicism]Of course it won't be, because they have all the necessary training/ skills to make sure none of the blame sticks to them. [/cynicism]

And insulting their workers, branding them with any kind of "syndrome", is never acceptable behaviour - it just shows management's lack of commitment to the Team and their desire to "distance" themselves from it.

Development is being slowed down either way, but doing the job slowly and more conscientiously (i.e. actually making stuff work) is far, far better than simply not delivering anything at all.

share|improve this answer
    
How do you mis-estimate when using story points? –  Dave Hillier Feb 12 at 22:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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