I am trying out Scrum in a project. Usually it is recommended (in Scrum guides) to keep two week sprints for every release. My client is asking to keep sprints to one week and release every Friday.

Sometimes members of the team are not able to complete assigned tasks due to technical challenges or perhaps they are on leave. In this case the sprint does not get completed and we miss timelines.

How do you handle escalations in these scenarios and how can the sprints be better managed?

  • 1
    Are the team members involved in sprint planning?
    – G.H
    Commented Dec 18, 2015 at 13:43
  • @G.H No team members are not involved during sprint planning. Client and Project Manager plan the sprints.
    – RKh
    Commented Dec 18, 2015 at 15:10
  • 3
    Well that's were things are going wrong ... You're not in anyway doing Scrum. Team members must be involved in planning, and estimation - after all it's these people who are going to be doing the work and these people who are in the best position to know what can be achieved within a sprint - no matter how long the sprint is.
    – G.H
    Commented Dec 18, 2015 at 15:23
  • 3
    This is not Scrum that is being implemented. The Team are the people in the best position to estimate what can be done in a period of time. If other people are saying what needs to be done without their input then it's bound to not get completed.
    – G.H
    Commented Dec 18, 2015 at 15:34
  • 1
    -1 don't tag it as scrum/agile etc if it isn't even vaguely.
    – Nathan
    Commented Dec 22, 2015 at 13:34

6 Answers 6


As has been recommended, invest some time reading the official Scrum Guide (there are not multiple).

Scrum does NOT require or even recommend releasing the software at any particular interval. It only mandates that work made "Done" within the Sprint timebox should be "potentially releasable" should the Product Owner decide to do so.

A Sprint is

a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

The choice of Sprint length should always be a business decision and never a technical one.

To better manage your Sprints, allow the Development Team to plan its own work and build its own forecasts.

Scrum says

Development Teams are structured and empowered by the organization to organize and manage their own work.

The whole development team should plan (read: not just a PM or a "lead" developer) the work it will undertake in a Sprint and must plan for conditions such as developer vacation, technical dependencies, etc. Doing this will increase the likelihood of realistic forecasts, better planning, and more trust with clients.

Did that help?


The duration of a sprint can be chosen from one week up to one month, and depends on a series of factors. If the client is asking to deliver more often you should try to understand what kind of value are you giving by doing this, and if your team is ready to handle this scenario. If not, and there's a good rationale behind the 1 week time-box, you should work towards it by reducing the obstacles that prevent your team from delivering every week.

That said, I might be wrong here, but it looks like something is not right in the way you manage your process. First of all, developers are not assigned any task in Scrum (pull vs push). There's a team that take into account a story and works toward its completion. Any pre-arranged leave should be taken into account when the sprint is planned, and as for the unforeseen leaves, they will not be "fixed" by reducing or increasing your sprint length.

If a story/task is not completed within a sprint the sprint does not fail (unless the PO cancels it), you will just deliver a part of what you've committed to. Not being able to complete 100% of what the team has committed to is something to be expected (and managed).

  • Please share a sample user story.
    – RKh
    Commented Dec 18, 2015 at 15:20
  • 1
    As a bank customer I want to log into my bank's website so that I can access my account information online.
    – WBW
    Commented Dec 21, 2015 at 23:19

Running a 2 weeks sprint does not guarantee that you'll be able to complete your sprint backlog when compared to a 1 week sprint. Longer sprint would mean a more tasks, so if you hit a technical challenge in a longer sprint it may affect deliverables anyways. Similarly, a team member taking one day off in a 1-week sprint would have a similar impact in a 2 week sprint, if your team member gets sick for a couple of days. Hitting an unforseen technical challenge or having an incomplete story during a sprint is ok as long as you discuss it in your retrospective to inspect and adapt your approach.

Possible advantages of shorter sprint:

  • Forces the team to split user stories into smaller chunks.
  • Better planning due to smaller backlog
  • Quick feedback from product owner / stakeholders
  • You inspect and adapt more frequently
  • Impediments get highlighted early
  • Leaves no time for procrastination and also minimal effects of Parkinson's law, which says work expands so as to fill the time available for its completion.

What to do when you have imcomplete stories? You may decide to split the finished and incomplete portions of the stories.

  • Who creates user stories? In my project, I explain the functionality of a screen on paper to the developer. The developer creates user story of that functionality. Probably, I am not doing correct way. Is the user story entire functionality or several functionalities combined? Can you share a sample user story?
    – RKh
    Commented Dec 18, 2015 at 15:17

The Sprint is a container for planning and not necessarily for delivery. Sounds like you need to read the Scrum Guide ()


Scrum is a management technique for complex work and only specifies that you should release no less than every 30 days. If you want to release every few hours, but plan monthly you can.

Your sprint duration should be governed by your effective planning horizon and that planning horizon, in practice, governs your maximum release frequency.

I would be happy with a team that plans a two week sprint, and releases to production every week.



In the comments it was asked:

Are the team members involved in sprint planning?

Your reply was:

@G.H No team members are not involved during sprint planning.

That's the root of the problem right there. The team needs to be involved in defining how much work they can do in a sprint. No one else can answer that question more accurately than the team itself.

The whole point of SCRUM is that the team decides, the team works, and then the team examines what they've done. During this examination, they can use the information that they've learned to do a better job planning the next sprint.

How do you handle escalations in these scenarios and how can the sprints be better managed?

In SCRUM, you don't escalate, you learn. You adjust how you plan so that you can better predict how much work the team can accomplish. If somebody else is deciding how much work you can do in a sprint, you'll never solve this problem.


I recommend that you frankly discuss the issue with your client. While, of course, they want to see "regular progress," insistence on things like "one week, and release every Friday" are counter-productive.

Yes, the team should try to "parse" its work into manageable units so that there is not an excessively-long interval between "usable releases," but there's also wisdom in an old Paul Masson winemaker's advertisement: "We shall sell no wine before its time."

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.