Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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).
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:
What to do when you have imcomplete stories? You may decide to split the finished and incomplete portions of the stories.
The Sprint is a container for planning and not necessarily for delivery. Sounds like you need to read the Scrum Guide ()
http://nkdagility.com/the-sprint-is-a-container-for-planning-and-not-necessarily-for-delivery/
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."
