Streamlined Scrum
Our team is just finishing our 4th two week sprint. I like certain aspects of Scrum, but there seems to be an awful lot of overhead. I've asked why this is necessary, but haven't heard a good answer yet.
What if we skipped all the planning and tracking, and just focused on getting the work done? Meaning we wouldn't size stories, or estimate how long tasks would take or how many stories we could finish, or do burn down charts. We'd just take stories from the product backlog, and do as many as we could before the sprint ended.
Wouldn't this be more efficient, without giving up anything important?
In the approach you describe, what would happen to the Sprint Goals? Would there be any purpose to sprinting at all? What do you think the consequences might be for incremental release and the management of risk?
> overhead
Thinking of it as overhead is your first mistake.
Scrum is about a lot of things, but one of those things doing the minimum amount of necessary overhead to delight customers with a fantastic product. Each component of Scrum has a purpose.
It sounds like you spend more time in your Scrum Events than you think is valuable. Have you asked the Scrum team what they think? What is your role on the team? Which Scrum events do you think have a non valuable purpose?
> just focused on getting the work done?
I'm sure the software developers at Myspace got a "lot of work done". Where did that get them now?
> In the approach you describe, what would happen to the Sprint Goals?
The sprint goal would be to complete as many stories as possible.
> Would there be any purpose to sprinting at all?
The purpose would be to create a potentially shippable release and demo it to the stakeholders.
> Have you asked the Scrum team what they think?
Everyone seems to love it, and I don't understand why. But today after I asked in our retrospective why we need all the overhead, someone later came to me privately and said he agrees with me, but he doesn't want to say anything.
> What is your role on the team?
Developer.
> Which Scrum events do you think have a non valuable purpose?
Almost all of the planning and tracking the developers have to do.
For example, if I'm given a story that I don't even understand, how can I be expected to figure out all the tasks and how long they'll take? And what would be the point of comparing my actual time against my wild guesses and trying to draw conclusions from that?
> I'm sure the software developers at Myspace got a "lot of work done". Where did that get them now?
But getting more done is better than getting less done. Working slower would not have saved Myspace.
If each Sprint Goal was merely to complete as many stories as possible, why would the team need to sprint at all in order to provide a release? Where would the advantage be in batching stories this way?
In Scrum, work is batched into sprints so that clear *business* goals can be met. If each increment meets such a goal, the development of the product can be de-risked accordingly.
If business risk is very low - for example, if each story represents a small, isolated, and well understood change - then alternative agile approaches such as Kanban may become viable. Business As Usual work often fits this pattern and it can sometimes be progressed as an unestimated stream.
Scrum, on the other hand, is optimized for dealing with uncertainty, where scope is unclear and backlog items can be weakly and/or tightly coupled. That represents a higher level of risk than individual stories can address. These risks can however be mitigated if each increment corresponds to a clear Sprint Goal of substantial business value. The events, roles, and artifacts of Scrum are all designed with the attainment of such goals in mind.
> If each Sprint Goal was merely to complete as many stories as possible, why would the team need to sprint at all in order to provide a release? Where would the advantage be in batching stories this way?
Well, they wouldn't _need_ to sprint. But I thought the point of sprinting is that instead of having to wait forever to get something they might not want, the end users get new releases often and they can give their feedback to drive future sprints.
I don't see why it matters if the sprint goal is to do stories A, B, and C, or just to do as many stories as possible (and completing A, B, C, and D).
> In Scrum, work is batched into sprints so that clear *business* goals can be met.
Wouldn't the stories meet the same business goals whether or not you spend 4 hours guessing how long it will take to do them?
> Scrum, on the other hand, is optimized for dealing with uncertainty, where scope is unclear and backlog items can be weakly and/or tightly coupled.
Yes, that's what we're dealing with on this project.
> That represents a higher level of risk than individual stories can address. These risks can however be mitigated if each increment corresponds to a clear Sprint Goal of substantial business value. The events, roles, and artifacts of Scrum are all designed with the attainment of such goals in mind.
Not sure what is meant by risk mitigation or whether we're doing it. I guess I'll look into that.
From your statements White Alligator, there are still areas related to Scrum that you and your team are not understanding completely.
Firstly, nobody on a Scrum team is given a story. Team members accept stories/tasks based on their availability. Nothing is "assigned" in Scrum.
Secondly, a HUGE red flag is your statement that you have a story in your sprint that you do not understaned. For any user story to be brought into a sprint, it needs to be understood by everyone on the team. If this is not happening, then that is a problem.
From your concerns, your team may prefer to work in more of a Kanban structure where user stories are pooled and prioritized, and teams simply grab stories to work on. The benefit to Kanban is placing queue limits on the various phases of the development effort (analysis, dev, testing, etc) to optimize team productivity, enforce a consistent flow, and uncover organizational impediments to the flow.
The reason that sprints are timeboxed is because there are 4 basic attributes to a project: time, cost, scope, and quality. In Scrum, 3 of the 4 are fixed. Quality = TDD, DoR, DoD. Cost = fixed team sizes. Time is fixed with a sprint duration. Therefore, the only attribute that can vary sprint by sprint is the scope: i.e. - how much to commit to each sprint.
> Well, they wouldn't _need_ to sprint. But I thought the point of sprinting
> is that instead of having to wait forever to get something they might not
> want, the end users get new releases often and they can give their feedback
> to drive future sprints.
In Scrum each release should represent a coherent piece of useful functionality. There's no point in batching work into a sprint unless the work being done, in aggregate, meets a valuable Sprint Goal.
> I don't see why it matters if the sprint goal is to do stories A, B, and C,
> or just to do as many stories as possible (and completing A, B, C, and D).
Neither of those would be credible Sprint Goals. A good Sprint Goal is more than the sum of individual items in a Sprint Backlog, and more than just the number of items selected.
Example: "This Sprint, we will allow new customers to register on the new site"
This goal would be derived from multiple items that were prioritized on the Product Backlog by the Product Owner, and which were negotiated into the Sprint Backlog during Sprint Planning. Perhaps the PO originally wanted *all* customers to register...but that would have been too much to take on...so the Scrum Team agreed to limit the functionality to new customers only. Existing customers, for the time being, will have to continue using the old site.
This Sprint Goal - to register new users - is the discrete piece of functionality that will be delivered by the end of the Sprint. The PO can set stakeholder expectations accordingly, and he or she can expect to be in receipt of a suitable potentially releasable increment at the end of the sprint timebox.
The items in a Sprint Backlog are secondary to and serve the goal. Remember that a User Story is nothing more than a placeholder for a conversation. A Scrum Team can and should replan throughout the Sprint as new things are learned and as scope is clarified. A Sprint Backlog can change substantially during a sprint in order to meet the agreed goal.
> Wouldn't the stories meet the same business goals whether or not you spend
> 4 hours guessing how long it will take to do them?
You won't have a business goal for a Sprint unless you formulate one. Sprint Planning isn't about guessing games. It's about discussing the backlog items with the PO, so a team understands the scope of the work being asked for, and the value of the next potential release. A smart team will spend 10% or so of each sprint refining the Product Backlog so it is in the best possible shape for estimation and Sprint Planning.
A Scrum Team should be able to enter Sprint Planning well prepared, with Product Backlog items either already estimated or sufficiently understood to be estimatable, and confident that few surprises are likely to be in store.
Ian, thanks for that explanation. I guess we are not formulating sprint goals because we didn't know we were supposed to. And I guess we are not entering sprint planning with well understood backlog items because some people don't think we need to.
Tim,
> Firstly, nobody on a Scrum team is given a story. Team members accept stories/tasks based on their availability. Nothing is "assigned" in Scrum.
The product owner happens to be my boss (in non-Scrum terms) and said "Can you do this?" Is the PO supposed to just wait for people to step forward and claim stories on their own? I would have volunteered to do these stories anyway, because I'm the only person on the team who has worked on this app, and I haven't worked on any other apps (I'm new to the company).
> Secondly, a HUGE red flag is your statement that you have a story in your sprint that you do not understaned. For any user story to be brought into a sprint, it needs to be understood by everyone on the team. If this is not happening, then that is a problem.
I guess we have a problem then. I'll accept a story and give my task breakdown with the hours. Then after the planning meeting, I'll have to go talk to someone to find out what the story means. Then I can ask the product owner for clarification on exactly what they want. Then I'll find holes and we'll need to ask the customer for more details. There's often a lot of back and forth before I even know what I'm trying to do, much less know how I'm going to do it. Is this not normal?
I've only worked at one place where we had good requirements up front - the one place where I've used the waterfall method. While Scrum does not forbid requirements documents per se, many Scrummers seem to think that they're a bad idea, and that the requirements should be figured out during the sprint.
> From your concerns, your team may prefer to work in more of a Kanban structure where user stories are pooled and prioritized, and teams simply grab stories to work on.
That sounds better to me, but there's a big company-wide push for Scrum right now.
> For example, if I'm given a story that I don't even understand, how can I be expected to figure out all the tasks and how long they'll take?
Product Backlog Refinement (formerly called grooming). See:
http://www.scrumcrazy.com/What+does+Product+Backlog+Grooming+Look+Like%…
(also be sure to see the links to other articles at the bottom of that page)
> And what would be the point of comparing my actual time against my wild guesses and trying to draw conclusions from that?
Scrum does not suggest tracking "actuals". That's not part of Scrum... that's something your team/org has added. Personally, most of the teams I coach find no value in doing that.
> But getting more done is better than getting less done. Working slower would not have saved Myspace.
Not necessarily. If your "working slower" turns out to have more value than your "getting more done" - then working slower would be better. If you "worked slower" and instead created Facebook, wouldn't that better?
> Almost all of the planning and tracking the developers have to do.
I suspect that that the reason your planning and tracking don't work is because you don't understand the work you're planning and tracking. Fix that problem with refinement practice, and the other practices might start to have value.
I'm assuming that you have stakeholders that are interested in release dates. If that's not the case, then maybe you don't need to plan or track. In the real world, I don't see this case often.
Charles,
> Product Backlog Refinement (formerly called grooming). See:
http://www.scrumcrazy.com/What+does...ok+Like%3F
(also be sure to see the links to other articles at the bottom of that page)
Good stuff, thanks.
> Scrum does not suggest tracking "actuals". That's not part of Scrum... that's something your team/org has added. Personally, most of the teams I coach find no value in doing that.
Interesting. They're telling us it's so that we can give more accurate estimates going forward (i.e., if your estimates are consistently too high or too low, then adjust accordingly).
> Not necessarily. If your "working slower" turns out to have more value than your "getting more done" - then working slower would be better. If you "worked slower" and instead created Facebook, wouldn't that better?
You're comparing apples and oranges. Creating Facebook faster is better than creating Facebook slower. Creating Myspace faster is better than creating Myspace slower.
> I suspect that that the reason your planning and tracking don't work is because you don't understand the work you're planning and tracking. Fix that problem with refinement practice, and the other practices might start to have value.
I hope so - we'll see.
> I'm assuming that you have stakeholders that are interested in release dates. If that's not the case, then maybe you don't need to plan or track. In the real world, I don't see this case often.
The stakeholders are interested in eventually getting a release, but I don't think they care exactly when. We told them in March that we'd have something for them in a few months. We have not released anything to them yet because it would be confusing for them to receive some of the changes but not all of them.
> They're telling us it's so that we can give more accurate estimates going forward (i.e., if your estimates are consistently too high or too low, then adjust accordingly).
There is some merit there, but you don't need hours to accomplish that. You can use story points and whether team can accomplish their forecast for the sprint or not. We also need to remember that software development is no exactly predictable (like the stock market), so trying to predict exactly is a bit of a fool's errand, or waste of time. The most important thing to try to get good at is forecasting how much work can be accomplished in a sprint, and making sure all sprints end with a potentially releasable increment of software.
see this article for more:
http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-bette…
> We have not released anything to them yet because it would be confusing for them to receive some of the changes but not all of them.
Usually, but not always, this is a sign that the PO doesn't know how to work with the dev team to break work in to smaller, coherent, releasable chunks. It is very rare for a system to have to go more than a few weeks or so without being releasable -- if you plan it right, and be sure your software modules are "loosely coupled".
Having stuff that is so intermingled that it's not releasable for a few months is typically, but maybe not always, a waterfall habit.
> http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-bette…
Fantastic article, especially the comments. It seems that Jeff Sutherland would agree that my team is wasting a lot of time. I could totally get behind Scrum if we were doing it his way.
One big goal of Scrum is showing all the issues a company has, it sounds like it's doing that in a great way :)
I'm just studying for PSM1, it's great to see you mention from practice all the usual examples of things that can go wrong ;)
It sounds like your Scrum Master needs to re-read the Scrum guide on here several times, and then push to actually start using Scrum without all the Scrum but's, you might enjoy it a lot :)