|Can't get to done, roll-over every sprint||Guarino||11/14/12 5:42 AM|
Hoping to get some suggestions on how to inspire my team to be more responsible for completing the sprints.
I have scrummastered for several years, and while most teams eventually work themselves out of the constant rollover, this particular team hasn't found their way yet. I am a very hands off scrummaster, allowing teams to determine their own processes, and try to only step in to help recognize problems and offer suggestions on how to move forward.
We are in 2 week sprints, but we used to do 3 week, this issue is not specific to either cadence.
The team checks in "some" stories throughout the sprint, but mostly the stories come in on the last day or two. We have done several things to try and stop this, the team voted to have a "code frost" date inside the sprint. This worked ok, but again all the stories showed up on the same day, instead of throughout the sprint.
What our "norm" now is, the majority of the stories are built and sent to "qa" on the last day or two, creating a rollover effect of the previous sprints stories. So now as qa is testing "last sprints" stories, the bugs that arise are top priority and developers get pulled off their stories to fix bugs from last sprints stories so they can pass.
This is somewhat a normal pattern of scrumteams, so I was not too concerned, and tried things like: Not buying new stories for a sprint to "catch up", assigning certain people to fix bugs while others worked on stories, have QA folks in the Developer Branch to help vet out bugs earlier int he process...
But they all seem to be fine with a "staggered sprint" approach.
The team has been together for almost 2 years now, and the rollover has always happened, but I was not too concerned since we are building new product and had a long way before we released. However, we have a product now in production, so we are trying to release every few sprints, but the rollover causes issues now. Looking back, I realize I should have been more strict on finishing sprints on time.
Of note, we have tried to have the dev actually help QA, but honestly the QA team didn't think it was fruitful at all, and they wanted to test every story anyway.
I tried to just have the PO rebuy the stories, but since they are on the "QA" side of things, the developers are left with nothing to do...
Any suggestions would be great, thanks all for your time :)
|Re: [Scrum] Can't get to done, roll-over every sprint||Mike Vizdos - ImplementingScrum.com||11/14/12 6:26 AM|
Sounds like a good topic to discuss at the next retrospective with the team.
What do they want?
Also... If you have been the ScrumMaster for a while with them you may want to bring in someone else who is skilled at facilitating and can stay neutral (this is not a personal dig against you it has happened to me before and I know this was effective for me in similar situations).
There will be more suggestions here.
Good luck with this.
|Re: [Scrum] Can't get to done, roll-over every sprint||Howard Sublett||11/14/12 6:36 AM|
Limiting the WIP may help them swarm on 1-3 stories at a time. Only having them break down 1-2 days of stories at a time and they have to meet the DOD before a new story can be broken down.
|Re: [Scrum] Can't get to done, roll-over every sprint||Ram Srinivasan||11/14/12 6:39 AM|
You probably are going to get a lot of questions from others as well, but I will go first ;)
From what it sounds like, it seems that dev and qa are separate teams? Are your teams cross-functional?
How are teams limiting their dev and qa work in progress ?
I have used story burn-downs in big flip charts and asked them to reflect on the "step" or "waterfall" (not SDLC, but the burn-down looks like a waterfall) pattern they see. Ideally they limit their WIPs, you should see a good "ski slope" in their story burndown.
--You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
|Re: [Scrum] Can't get to done, roll-over every sprint||Clinton Keith||11/14/12 7:53 AM|
Great questions by others. I'll add one:
Why does the PO find it OK to accept stories that are not complete if there is work left to do (testing)?
|Re: Can't get to done, roll-over every sprint||Sameer Bendre||11/14/12 8:34 AM|
Great points by others. In my opinion it's the culture issue at the place. Trying to find the root cause behind that could be time consuming and you may have to get in the mud with many people - PO, management etc.
I am facing same challenge and the way I tried to handle it, using the "leftovers" analogy. People can tolerate leftovers one or two meals. [Thanksgiving is coming, think about the turkey leftovers - how many days would you like to eat it? :)]
For 2/3 sprints I kept adding a new story called "Leftovers" which represented all unfinished work from earlier sprint(s). This sprint a team member spoke out saying we don't like that term. This opened up a discussion that led to team agreeing to under commit, clean up the pending items and next choose/plan wisely and realistically. We didn't have to wait till retrospective to address this issue.
It's all about challenging the status quo to unearth the actual problem. If the team really wants to address it, great. If not, it's an accepted culture and you will be in a minority who is trying to disrupt their comfort.
I would be happy to return and report on our progress on handling the leftovers after next 2/3 sprints.
Guarino - Thanks for bringing a very interesting topic that people are uncomfortable to talk about.
Appreciate the questions and pointers from all agile practitioners, Thanks for sharing.
|Re: [Scrum] Can't get to done, roll-over every sprint||George Dinwiddie||11/14/12 8:35 AM|
You've gotten some good advice. I'll try to add some things others
What would make the team want to do a better job? You can lead a buffalo
anywhere you want, as long as he wants to go there.
It sounds like people might be working individually, rather than as a
team. Are they working in cubes? Or at a big common table in a team
room? The latter makes collaboration easier, in my experience.
Are they working on individual stories, or do they swarm over the
stories to get them done?
Do they have clear concrete examples of the acceptance criteria at the
start of the sprint? Or just general descriptions?
Are the stories considered "done?" What technique are you using to
determine how much work to take on in the next sprint?
I wouldn't call it normal, nor would I call it Scrum. I have seen it
What do you mean by "seem to be fine?" Have you asked them? Or have they
just come to think of it as inevitable and unfixable? Is it talked about
in the retrospectives?
When I've seen this, the testers were quite frustrated and unhappy about
it, but felt powerless. The programmers were annoyed at being
interrupted about stories they considered finished, but didn't connect
that annoyance to the root causes.
You might find
in case it's a problem of not knowing any other way to work.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
|Re: [Scrum] Re: Can't get to done, roll-over every sprint||Ron Jeffries||11/14/12 10:33 AM|
|Re: Can't get to done, roll-over every sprint||Guarino||11/16/12 6:20 AM|
Thank you all for your help and suggestions.
I will try to answer these questions, to see if it strikes any other thoughts.
I tried to leave out my opinions in the original post, as someone mentioned getting a 3rd party to help out (that is you guys :) )
We have 2 "QA" members on our team. The company has a QA department, but they are spread across the teams. So its cross functional, but the roles are fairly well set when it comes to Who can pass a story to ready for acceptance.
Our PO doesn't accept the stories until they are "done", so they end up rolling over and they get accepted in the next sprint. To that end, our monthly productivity is fine, its the fact of not completing sprints that is causing anxiety on the team.
The team is wanting to go to staggered sprints, this is what they want to do. Though I am hands off, I do feel it is important to try and stop this decision, perhaps I should let them do it? My guy says no, because the problem is still the problem. As someone mentioned above, my interest is in finding the root cause of the issues.
IMO (and as someone mentioned above), I feel development mostly feels that they get the whole 2 weeks to try and finish. This I "think" gets the deadline mentality of, "I have until friday to finish, therefore it will take me to friday". Not on purpose, of course, the team works hard.
The team doesnt swarm very well, even with some prodding to get 2-3 devs tackling some of the bigger stories first, while the others start picking low hanging fruit, they still seem to work silo'ish.
Atmosphere is great here, we dont work at a common table, but its close to that. We have half group like cubes so the team is together, and there are no obstacles for open discussion (white boards everywhere, etc), but their personality is more to stay to themselves.
I have thought about WIP, I am not quite sure I want this to be honest. I would rather approach it via DSM, determine who's story could use help and have someone help. They will do this if prodded, so have recently been working this as ideas via the DSM. I will ask specifically when someone says they "worked on x, still working on it" to see if someone else has time to help. This is actually starting to work, so I didnt want an official process of WIP if they can organically create this atmosphere.
Acceptance Criteria is a bit tricky, and is one of the things I am working with our PO on, it is an issue with this team, and does feed a bit of this, but mostly it is a nonfactor, the team during planning and DSM etc, eventually get to stories end in the "points" assigned to the story. But I am not closing my eyes to this, we have it in our sights :)
Sorry I am typing so much, but its just not an easy problem to solve. I appreciate everyones willingness to comment and suggest.
|Re: Can't get to done, roll-over every sprint||Woody Zuill||1/7/13 11:31 AM|
I hope you have made some progress on your "getting to done" issue.
There is already some great advice given in earlier replies, so I'll just make a few observations and provide an idea or two.
I've had the same basic situation you describe many times, and I've talked with numerous ScrumMasters and Agile Coaches who have dealt with this as well.
[Just a note - "WIP" is what you have already - it is simply the "work in progess" - the work that has been started, but is not yet finished. Scrum provides one way to limit WIP. Some teams use a "Sprint-less" approach, such as kanban. I'm not recommending that as such - you can get great results from either doing Sprints (iterations) or following a kanban approach. The key in both approaches is to limit the work and get it done before taking on more work. ]
It sounds to me that it's possible the problem isn't as much "not getting work done" as it is not having an environment where "getting work done" is considered important.
One one team a few years back we had the same problem. This is a "real-life" example of one way to make progress on this sort of situation:
- Problem: Even thought the team was working on a prioritized Scrum Task Board with the stories on the broad in priority order from top to bottom, some team members would choose work near the bottom of the board. This would also often be just "part" of a story (a few of the tasks) they felt they could accomplish. A lot of work was only partly done at the end of the Sprint.
- There were many reasons this happened: wanting to do something they felt they were best suited to work on, taking on something they felt they had a chance to complete, wanting to work "alone" on something, etc.
- The Solution we came up with: Allow only one story at a time on the board, and make that story the highest priority item. The whole team would work on that one story until it was DONE, and only then would we put the next story onto the board. If a team is reasonably sized so that it can work effectively as a team this can work very well as the team is learning to stick to the most important items. This is very similar to kanban, but was used in this case as a tool for learning how to focus on one thing until it is done, and how to work with others to be effective in doing so.
- An Observation: For this to work, the team has to be a realistic size, and should have all (or at least most) of needed the skills/abilities to do the work. If needed, this could be done "as an experiement for a couple of Sprints" with the idea that "we'll learn something" while still getting work done - you might see some interesting improvements happen quickly. We did, anyway.
- HOWEVER: If you can't get anyone to buy in on this or other possible paths forward, you might be exposing another issue: The ScrumMaster role requires being skilled and capable at guiding a team in accomplishing continuous improvement. You stated about yourself: "I am a very hands off scrummaster". This might be a time when more "hands on" is needed. I take these situations as a time to reflect and "tune,adapt, adjust" my own approach.