13

What should be the attitude towards getting stories done that are assigned to a sprint? Obviously you want to prioritize getting them done in the sprint, but to me the whole point of agile is to be dynamic: You don't want to deliberately procrastinate or make it "ok" to miss finishing user stories in a sprint, but at the same time when unexpected things come up, and those stories do not get completed and are pushed to the next sprint, you don't want the feeling that you did something wrong. That shouldn't be a scary or negative experience, should it?

Are negative/scary experiences acceptable for missed sprint commitments? Should developers be held accountable for missed sprint commitments when unexpected tasks come up that must be dealt with (Eg. production support)?

maple_shaft
  • 26,570
void.pointer
  • 5,113

9 Answers9

7

You should absolutely aim to get items done within a sprint.

One of the main benefits of SCRUM is that it gives the project a 'heartbeat'.

You prioritise, pick items off a list, you deliver them, you demo them, you reflect how they went, then you do it again in preditable cycles.

All of the planning, estimations and prioritisation are based off of this concept. That we can and will commit do X points within the sprint, and can, over time, establish a velocity from that we can use for better planning.

If you are too casual over the content and commitments of your sprints then SCRUM just breaks down in my opinion and you lose a lot it's benefits.

Of course the real world will sometimes have something to say about this, but that should be the exception rather than the rule....

Benjamin Wootton
  • 725
  • 5
  • 9
6

The key is that there needs to be accountability around not getting the stories complete.

That means there should be a solid reason why a story was not complete, and that this reason is accounted for in the project plan going forward so it is not repeated.

This reason needs to be more than a vague "stuff came up."

For example, if a story was not complete because a team member had to work on a production problem, then this possibility needs to be addressed in future iterations -- either by planning for fewer hours from this team member or arranging for other coverage.

If the reason could have been avoided with more diligence or hard work up front, then, yes, this accountability may be a little painful. Hopefully, the pain is of the "This is what we need to do better next time" variety rather than the "You're not doing your job" variety.

JohnMcG
  • 1,747
4

That shouldn't be a scary or negative experience, should it?

If it happens once or twice, no, then it shouldn't be a negative experience. If it happens regularly, you have a problem. The team is then always overcomitting. Get better at estimation and think twice about what you commit for a sprint, but don't become anxious.

Relaxed sprints mean you had an undercommittment.

Unrelaxed sprints mean you had an overcommittment.

I just deliver what I commit and try to get better at committing. Only under special circumstances would I move a story to the next sprint. I prefer to have slight pressure every day than to have a hell of pressure shortly before some deadlines.

Falcon
  • 19,388
4

Based on my experience - Like anything else in agile, we adapt to a continuous feedback system including the estimation.

It is OK to miss a deadline for the first sprint (beginning of the project) but you LEARN from that what went wrong (under-estimation, not knowing the team strengths etc). Then you take the feedback and feed it to the next sprint and you get a better estimate.

From my experience, It has been 11 months on my new agile project we rarely miss the deadline now if at all we miss it. But we did miss the deadline for the first sprint because we did not know the pace and strength of our team members.

Some folks argue that "allocate" more time for the first sprint to overcome the first sprint problem.

java_mouse
  • 2,657
  • 17
  • 23
3

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. - Principles behind the Agile Manifesto

If it's a scary or negative experience, and it happens all the time, you have a problem. Software development should be fun. Not negative or scary.

However, if the team is committing to finish some stories in a sprint and continuously not delivering, you also have a problem. This problem is almost certainly not going to be solved by adding more pressure on the team to complete the stories. If the problem is due to external factors, those need to be managed. If the team is over-committing the ScrumMaster can guide the team towards committing to less story points. There can be many reasons and each may need to be addressed differently. An energetic and motivated team should have plenty of motivation to move forward.

Ideally whatever the problem is, it is raised during the retrospective, and fixed.

It shouldn't be that complicated for the team to figure out what they can accomplish during the relatively short period of the sprint and then accomplish it (an occasional story that gets pushed to the next sprint is OK, velocity can fluctuate, things change etc.). If you can't get that going reasonably smoothly after a few sprints you're doing something wrong.

Guy Sirton
  • 1,895
2

It's interesting to see the answers / comments here. On every agile (type) projects I've worked on, the primary advantage was to spread the deadline pressure over many mini deadlines rather than a deadline death march at the end of a project. IMO, the sprints should be taken seriously. Any slips in deadline or functionality delivered should be viewed as potential problems in either project management or development.

tzerb
  • 563
1

It really depends on your timeline.

Sometimes you will NEED to get all the stories done, or most of them anyway. While Agile does provide some flexibility, you will also need to get the project done, possibly on a tight timeline.. So, having most of the stories done will let you get your project done in time.

With that said, though, stuff is going to come up that will prevent you from getting every story done, every sprint.

If the product is on a timeline and key stories are missed, that coudl make the product late. The product being late in some cases can hurt a company's competitive position. So in that case, you might WANT it to be a negative experience to have stories missing - it might make you get it all done the next time.

Alan Delimon
  • 440
1

When dosed correctly, stress is good. You want don't want to take away all stress, you just want to spread it out more evenly in time. Even when you play your favorite game, you will have some amount off stress and negative feelings. You actually get more energy out of it.

A team should genuinly feel bad about missed stories. It will give them energy to change something next time (work differently or plan less stories, both are good). They should also feel proud when they make their stories, of course.

You also mention unexpected tasks (production support). That raises a red flag with me. There should have been an agreed time box for all issues unrelated to the stories. Otherwise the game isn't fair, the team feels helpless and the negative feelings aren't used to improve.

Kris Van Bael
  • 1,378
1

You should look at the factors which makes your commitments fail and try to fix them. Large amounts of random events will keep messing up your sprints making your velocity unpredictable. Either fix the causes of this or introduce slack in your sprints. I prefer fixing.

Either way, the team cannot be held responsible if their job is disturbed by external factors. Use retrospectives to look into this.

Martin Wickman
  • 13,365