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)?

Improve this question
11
  • 2
    This so depends on team and company culture, that there is no one right answer... Voting to close as not constructive.
    – Oded
    May 1, 2012 at 15:33
  • 4
    @Oded that sounds like a cop-out answer. You're basically saying it's OK for a company to make a negative and potentially abusive experience out of sprints?? Let's talk ideals here. I'm not asking you to generalize anything.
    – void.pointer
    May 1, 2012 at 15:35
  • 1
    In ideal world with unlimited time and resources there should be no stress. That doesn't help you though.
    – CodeART
    May 1, 2012 at 15:51
  • 2
    @RobertDailey It's not a cop-out at all -- this just isn't an answerable question. Of course it's far better for work to be a positive rather than a negative experience, and actual abuse is never okay. But even at a single workplace, on a single project, the atmosphere will vary. Sometimes there's a lot of pressure, sometimes not so much. That's true of any workplace, agile or not. If you're consistently unhappy at your workplace, do something about it (fix it or leave), but don't expect your next company to provide low pressure and high satisfaction 100% of the time.
    – Caleb
    May 1, 2012 at 16:08
  • 1
    @Robert - My last few comments were generic in nature and not a reflection on the question as it stands now. I was trying to explain to bjarkef that close votes are not cast based on how interesting (or not) a post may be. My last comment to yourself is also an attempt to explain that some questions have no home on any SE site. Again, these are general remarks, not directly to do with the question.
    – Oded
    May 2, 2012 at 15:17

9 Answers 9

Reset to default
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....

Improve this answer
1
  • One of the main benefits of SCRUM is that it gives the project a 'heartbeat'. The same can be said of any Agile methodology.
    – maple_shaft ♦
    May 1, 2012 at 16:42
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.

Improve this answer
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.

Improve this answer
1
  • Negative experience covers many different scenarios. One friend had quite the negative sprint experience mostly due to the team not "yet" getting the concept of the sprint down. In their effort to improve release cycle, they basically sped up the death march and called it a sprint.
    – Edwin Buck
    May 1, 2012 at 23:18
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.

Improve this answer
4
  • So if you rarely miss a deadline, you will naturally often not have anything to do at the end of the sprint. What do you do then, take new items in or just take the time off? :)
    – Bjarke Freund-Hansen
    May 2, 2012 at 10:48
  • @bjarkef Once the sprint is over, we get the next sprint started and running. I always felt that the downtime while using "scrum" is very less compared to "traditional" development.
    – java_mouse
    May 2, 2012 at 12:02
  • So you don't have a fixed length of the sprint, you start the new one when the old is done?
    – Bjarke Freund-Hansen
    May 3, 2012 at 6:10
  • 1
    @bjarkef - we have fixed length of 2 weeks. once the weeks over and delivered,we will start the next spring immediately.
    – java_mouse
    May 3, 2012 at 13:37
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.

Improve this answer
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.

Improve this answer
2
  • Such that you are constantly working under pressure? That sounds like a lovely working environment.
    – Bjarke Freund-Hansen
    May 3, 2012 at 6:12
  • 1
    Enough pressure that the team gets a crapload done but not soul crushing pressure that can sometimes come with finishing a project. But yeah, it's not for everyone.
    – tzerb
    May 3, 2012 at 13:51
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.

Improve this answer
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.

Improve this answer
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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