The 1-Week Sprint Dilemma!
Background: I am the SM (also wear a different hat and act as the PO) for a team that consists of junior and senior developers as well as QA Analyst (I do know Scrum states that everyone is a Developer). We do have a product backlog, but it's not really one product but rather various short-length projects that can be done usually in a couple of weeks to a couple months. Our stakeholders are typically internal to the organization.
Our DoD has two levels: presentable for feedback (Dev complete), and quality assured (QA complete). To be releasable we should be "quality assured".. but we will still present the "presentable for feedback" items in the sprint reviews only to get feedback.
Context: I have agreed with the team to have 1-week (6 business days in reality) sprints for our projects.
The reason for this is
1) I want to minimize the risk to 1 week, since the projects aren't usually that large, so anything more than one week is potentially a significant chunk of the project.
2) Initially we had longer sprints, and I realized the team (new to scrum) tends to start slow and scramble in the end, which would mean stuff wouldn't get done and impact would be relatively big. So I thought 1-week sprints for a while will help fix that habit through frequent inspection and adaptation
3) I felt that the PO/organization/stakeholders are not getting enough transparency on the progress of the projects as per the feedback I had got. With 1-week sprints we can have more frequent reviews and more opportunities for showcasing the current progress. This is especially true in my opinion, because as mentioned, the projects don't span across so many weeks. So if a project is estimated to complete in 1 month, with sprints larger than 1 week, you don't get many reviews/retrospectives/plannings or opportunities for inspecting/ adapting ...
Problem: Organization's processes are such that usually the development of a project/build/story has to be fully completed, and then passed to the QA analysts to get their sign off. Also some of the scripts must go through a review process, done by people external to the team, which can span 1 to 4 days. Usually QA is not allowed to start testing the story pending review until this review process is at completed at a certain tier of the review process.
Our senior dev keeps complaining about the sprint length now, and I partially agree with some of his points. For us, this 1-week sprint means it's very hard for a 5-story point story for example, to go through all the stages of Dev-->QA or script review within the one week sprint. We do try to break things down to smaller chunks, usually 1 to 3 SP. But this is not always possible, because for some stories, further break down makes it hard to be something that can go through QA! The developer thinks longer sprints will help us go through all those stages to deliver higher velocity in the sprint and things feel less rushed. And if they don't commit to such a story, then Dev won't have a lot to do in the sprint and we may waste time due to sprint length.
My suggestion has been to keep the 1-week sprint. I prefer shower lower velocity, and frequently than showing higher velocity and not-so-frequently, though the senior dev really likes to put a lot of related features together in sprint (then argue that it's short :) ). Usually stories that are incomplete or pending QA at the end, go back to backlog and get re-estimated to be done in next sprints.
Sorry for the long post. I appreciate you guys' feedback based on your thoughts and experience. What would you do in this kind of situation?
Hi Nima,
to me, from what I understand, there are couple of issues:
1) Done Increment is not releasable
2) As a Scrum Master and PO you have conflict of interests
3) Team might not be cross-functional (you wrote: "team tends to start slow and scramble in the end, which would mean stuff wouldn't get done and impact would be relatively big", which might be the symptom)
4) The team might not have required skills to complete a Done Increment
> I felt that the PO/organization/stakeholders are not getting enough transparency on the progress.
Are you the PO or someone else? You feel it or you know it?
That sounds like a challenging environment to play Scrum. I have an impression that sprinting is faked and, rather than provide value, is more a way to control the progress and put some time pressure on a team. Answers to those questions would help me understand better your situation:
- Why Scrum was chosen here?
- What value it provides compared to other Agile approaches?
- What's the team size?
- What's the mean for project length?
> I am the SM (also wear a different hat and act as the PO)
Let's put aside for one moment the potential conflict of interest in having the same person as both Scrum Master and Product Owner, and focus on the bare assertion that you perform both roles.
> Problem: Organization's processes are
> such that usually the development of a
> project/build/story has to be fully
> completed, and then passed to the QA
> analysts to get their sign off. Also some
> of the scripts must go through a review
> process, done by people external to the
> team, which can span 1 to 4 days.
> Usually QA is not allowed to start
> testing the story pending review until
> this review process is at completed at a
> certain tier of the review process.
In Scrum, a team should have control over how it performs its work to create an increment, and it is expected to self-organize accordingly. So how is it that you can be both the Scrum Master, with a responsibility for how Scrum is best implemented by the team, and the Product Owner, with a responsibility for optimizing the value delivered by the team, and yet it is the "organization" which decides how work is done?
My advice is to look carefully at how the Scrum roles are being fulfilled in this situation. I think that's the primary concern at the moment, rather than the sprint length.