1

I run 1 week sprints, lately my sprints are finishing ahead of schedule (one day before the end of the sprint) for one member of the team.

I know that some PMs wait until the next sprint cycle, however that means losing a day doing no work.

What's the best way to deal with this?

Improve this question
0

4 Answers 4

Reset to default
4

You have a few options at your disposal.

  • Use the available time to work on technical debts or fix bugs.
  • Ask the team member to share load another team member to help her/him in completing the sprint backlog because its a cross-functional team and its their shared responsibility / commitment to deliver sprint items as a team.
  • Pick the next highest priority item from the backlog after discussing with the Product Owner. Try to break the item down into a smaller or thinner slice which can actually be completed in the same sprint.

Sklivvz wrote the following in this answer:

you can add stories to a running sprint, if the team agrees to it. It's not a good practice though as it reduces the usefulness and predictive ability of the methodology

Same approach is also mentioned on this blog post:

I recommend you conduct a product grooming session which in this case acts as a cutdown sprint planning session for the small amount of new work that could possibly fit into the remaining time. If the new product backlog item(s) get completed before the end of the sprint their corresponding story points will count towards the velocity

Improve this answer
3
  • I thought about getting a team member to help the other team member who hasn't completed his sprint, the problem I had at the time was that he was not trained to help him anyway. So it would have been wasteful allocating the resource that way.
    – bobo2000
    Commented Apr 25, 2016 at 12:08
  • @bobo2000 yes, I agree. Hopefully now project knowledge is shared across team members.
    – Aziz Shaikh
    Commented Apr 25, 2016 at 13:40
  • 2
    I would add a "fourth bullet point", or consider blending it in every few sprints regardless - "Let them work on what matters to them most". It's amazing what teams will do when you let them be autonomous on the priorities once in a while. Perhaps it's fixing an annoying legacy bug they keep seeing in demos. Perhaps it's learning about a new piece of tech.
    – Jeff Lindsey
    Commented Apr 26, 2016 at 18:56
1

Typically with Scrum we have a product backlog that contains a list of the work we expect to do in the future.

At the beginning of each sprint the Product Owner and the team sit down and discuss which stories to take from the product backlog in to the sprint. A lot of teams use a metric called velocity to determine how much work to bring in to the sprint.

Now the sprint does not always go as expected. If there is unfinished work at the end of the sprint then we may reduce our velocity and so bring less work in to future sprints.

Similarly, if the work allocated to the sprint is completed before the sprint ends then we do the following:

  • Talk to the Product Owner and see if there are any prepared stories on the product backlog that could potentially be brought in to the sprint.
  • If we bring more work in and complete it by the end of the sprint then typically the velocity will increase and as such we will bring more work in to future sprints.

Experienced Scrum teams will often ensure that the stories at the top of the product backlog are small and are ready to start. That way, if they finish the work allocated to the sprint early it will be a simple matter to bring more work in.

Improve this answer
2
  • Velocity is a great concept since it tells you how well the sprint is going based on the stories in that sprint. The only problem that I have with it, is that very often velocity is dependent on many factors, and for it to be consistent, the stories in every sprint cycle have to be similar. How do you deal with that? Based on what you have said, am I allowed to bring more work in if they finish their sprint early? As opposed to waiting for the next sprint cycle to start?
    – bobo2000
    Commented Apr 25, 2016 at 12:05
  • Definitely bring more work in if you have the capacity to complete it before the end of the sprint. I would advise against bringing work in that you know you will not have enough time to complete. Having a reliable velocity can be a big challenge. One trick that helps is to have as small stories as possible, that helps to reduce variations between stories. Also, it is worth discussing at your retrospectives if there are ways to reduce the factors that impact on your velocity.
    – Barnaby Golden
    Commented Apr 25, 2016 at 12:16
1

You're a PM assigning tasks to individuals. You've used the word sprint, but isn't scrum, what is it?

The Scrum answer would be for the development team member to move on to whatever task helps the Team achieve their commitments. Whether that is picking up 'someone else's task' (this isn't a thing in scrum) or pairing. The thing about pairing is that if the team member lacks the skills to help another, this helps them aquire them.

I would recommend against pulling more work until the team has capacity, not just an individual. Improve cooperation so that everyone can work on the current work in progress first.

Improve this answer
0

Well first of all, you should wait and see whether this is a one-timer. If this is happening more often, discuss with the team, why they are committing to this amount of story points, although it's obvious, that they could handle more.

It's also an option to have a small RnD project, which can be processed in such cases. Perhaps it makes sense due to some strategic goals. It's also a good motivation I think.

To be honest, I've never faced such a scenario, since we have a bug-first policy here, which are usually, unplanned effort and therefore lowering the amount of available feature development time.

Edit

As I said in the comments it's optimizing performance by repeating. The best thing of scrum is, that there is an agreement between PM and DEV, which is made on eye level. This agreement must be adjusted, so that nothing is left at the end and no time is wasted. It's normal, that at the beginning the agreement is not ideal but it will definitely become it sooner or later.

If you're now optimizing from your site by giving them an additional story within the sprint, it's a normal hierarchical situation and it might lower the motivation of the team.

So be patient, and let the team learn its lessons as well as you have to learn yours. Let's say Week 1 the commitment is 30 SP and they are done by Thursday morning. Then in Week 2 the commitment could be 40 SP. Now they couldn't finish. No problem, on Week 3 the commitment should be 35 SP. Performance optimized with 3 weeks. Of course you might face the issue, that, although you've have found an "ideal" commitment, the result is far from being ideal. But this is also normal, since you're dealing with human beings and not machines.

Improve this answer
9
  • New team, finding it hard to get the velocity perfectly right. How can I get the story points extremely optimised?
    – bobo2000
    Commented Apr 25, 2016 at 11:12
  • @bobo2000: Well especially, in that case. Sit and wait. Convince them to take an additional story in the next sprint. Show them relative increase of performance then. It's a good motivation. All these agile approaches have one thing in common. They are all iterative and their goal is optimization of performance by do it, review it, modify and do it...
    – DHN
    Commented Apr 25, 2016 at 11:23
  • Can I add new stories to make up for the time left?
    – bobo2000
    Commented Apr 25, 2016 at 11:24
  • @bobo2000: No not in the current sprint. There was a commitment made by both sites. But for the next sprint you should ask to accept one more story.
    – DHN
    Commented Apr 25, 2016 at 11:27
  • And what if I add the additional story and they can't complete it because it is an additional day's worth?
    – bobo2000
    Commented Apr 25, 2016 at 11:29

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.