During a sprint, should we try to achieve 100% user story completion or 100% productivity

Question

We know that during every sprint, the team's primary goal is to achieve 100% completion of user stories which are part of the sprint backlog. But what happens in practice is that, development should be completed 2-3 days prior to sprint end, so that ample time can be spent to complete testing tasks.

Now, due to pressure of completing all user stories, the team can't pull another one since they know they will not able to complete it. Which means, either developers have to analyze next sprint tasks (which still may leave some spare time) or have to sit idle.

Some people may argue that planning was not good. But aren't we following Agile, where estimates may vary from actual (which leads to carry over of user stories) or maybe the scrum team completes all user stories in less time as compared to original plan.

Suppose the team is pulling another user story and didn't complete it. There is argument, it doesn't look good from management perspective that user stories are getting carried over.

Isn't the pressure of completing all user stories, which are pulled in a sprint, somehow decreasing the productivity of the team?

Answer 1

100% user story completion vs 100% productivity

Think in terms of value delivered vs utilization. Goal of Scrum team should be to maximize output and not maximize utilization. Anything (whether a machine or person) working on 100% capacity for longer duration will eventually break.

The goal of Scrum is not to achieve the highest resource utilization; it is to achieve the highest throughput of completed, deliverable value.

Article - The Case of the Time Tyrant (2008)

Full utilization concept may fit well in the traditional project management domain. However, software development is usually not a predictable / well-defined process, it is more of an empirical process in which you may end up in a situation where you have to discard a full days worth of work and restart from scratch. People have to attend meetings, answer to support calls, etc. in addition to writing code. So it may happen that a story gets completed earlier than estimated (or may get delayed too).

Maximum utilization can be counter productive

You should push back on 100% utilization part because maximum utilization can be counter productive in software development.

Scrum is about transparency and setting correct expectations. Stakeholders need to know when a particular piece of value will be delivered instead of how many hours of a developer were spent to complete a story.

What to do if you find idle time

I agree with the fact that sprint backlog should be completed some time before the sprint end date so that it can be tested and team can finalize a stable build after the required bugfixing etc. So developers may fix issues which were reported during testing within the current sprint. In case the team consistently performs well on the QA front and not many bugs come up then you may reduce this sprint end testing time and in future sprints the team may add more stories to the sprint backlog.

In cases where the team finds some idle time, the team may consult Product Owner to pick a story from product backlog which is next in line or can be completed in the remaining sprint time. Alternatively, if there are technical debts to pay then the team can also work on those.

In case of stories being carried over to future sprints, the Scrum team should not be held responsible for stories which were not part of the sprint backlog to begin with.

Answer 2

If you follow the Scrum framework strictly, you will not change a sprint's backlog after the planning. This means you will not pull another story. Free time at the end of the sprint can be used for minor refactoring, reading about technologies, optimizing you work environment, exploring new tools, and so on. There's always something to do, if you look closely.

This doesn't mean that you should finish every week after 4 days. If you (i.e., the team?) start feeling that you really don't have enough work, you should start pulling more work in the planning. If there's still space left and the next story is too big: break it down; pull the first part. The agile trick to productivity is to break stories down. Only when they are small enough, you can really measure your velocity.

Another thing: you are not going to hell because a story doesn't get completed. It's something that happens, as you cannot predict everything. If it happens you should analyze the reasons. Unpredicted problems? Maybe invest more in analysis next time. Too much work pulled? Adjust your velocity.

In any case: bring this up in the next retrospective. Discuss it with the whole team.

Answer 3

Your question seems to boil down to: "I have developers sitting around doing nothing for the last couple days of each sprint. What should I do?"

1. Have the developers help with the testing. It's a cross-functional team. Sure, the developers might not be experienced testers: so give the testers the exploratory testing, and give the scut work to the developers. This will help motivate them for point #2 below.

2. Have the developers help automate the testing (if you're spending 2-3 days testing a sprint's worth of stories, I'm guessing at least half of that could be automated, either as acceptance tests or as unit tests).

3. Get testers, developers, and the product owner together to create acceptance tests for stories at the beginning of the sprint. Unless a story involves some wholly new interface, you can probably write or reuse fixtures to test it before it's coded.

4. Don't call stories "Done" before they're tested. Go over your definition of "Done" to make sure it's what you want (or need).

5. Find useful uses for the slack time: setting up or improving Continuous Integration, automating deployment, doing coding katas. If a bug is found, switch to fixing it.

Yours is a nice problem to have. Don't blow your opportunities by pulling in more work than you can do.

Answer 4

If one more story can not be started 2-3 days prior to the sprint end, it is too large. Smaller stories can be started later and will reduce your productivity issue.

Answer 5

The first problem with your team's approach is that tests shouldn't be done after code completion. You should apply TDD or test-first approach especially if you're using agile methodologies. Developing and designing unit tests, system tests, acceptance tests before starting to write code etc should be implemented in various stages of the sprint by pairing testers, developers and even analysts and UX designers.

Developers don't sit on their hands after completing their development tasks. They still have tasks which depend on code completion like technical documentation, UX modifications and of course modifications to the code which could be found by various kinds of tests (exploratory tests, installation tests, integration tests etc) after the code completion.

Answer 6

The goal of the team should be to complete 100% user stories at the end of Sprints. If they couldn't complete the user stories then there some mistakes in your estimations.

To avoid such things, when you call for Sprint Planning Meetings, explain the requirements to your team. Team includes devs, testers, designers, dba, etc. Then ask your team to estimate the effort required to complete each user story. In this way you can get an idea of time required to complete each tasks.

Business Analyst and Product Owner should prioritize the user stories according to business needs. Then take up the stories that can be completed in a particular Sprint. In this way you are not setting up unrealistic estimations on your team and your team can deliver 100% user stories and your management team will be happy with the results (which will never happen because they always expect more :P )