Teams used to a sequential development process have become accustomed to hand-offs between specialists. Analysts hand their work to designers who hand it to programmers who pass it on to testers. Each of these hand-offs includes some overhead in the form of meetings, documents to read and perhaps sign, and so on. In part because of this overhead, the hand-offs tend to be of large amounts of functionality. In the purest meaning of a waterfall process, the entire application is handed from group to group.
Teams that are new to agile project management often do not go far enough in eliminating these hand-offs. They often make the assumption that the programmers should finish programming a product backlog item before handing it off to the testers. This results in lengthy delays at the start of a sprint, when the testers are waiting for a first product backlog item to be handed to them. On a Scrum project, the unit of transfer between disciplines should be smaller than an individual product backlog item. That is, although there will always be some hand-offs (not everyone can be working on everything all the time), the amount of work being transferred from one person to the next should generally be as small as possible.
To facilitate these small transfers, Scrum teams learn to work by doing a little of everything all the time. Rather than an analysis phase (done without the programmer and tester) followed by a programming phase followed by a testing phase, a little of each of those activities is happening at all times.
Even with an emphasis on minimal hand-offs, there will be some product backlog items that will require a week or more of programming time before the programmer can give something even beginning to be testable to a tester. That’s OK. Not everything can be split as small as we might like. To avoid a flurry of testing activity toward the end-of-sprint, avoid bringing a bunch of these complex items into the same sprint. Instead of planning a sprint with, for example, three very large items that cannot be partially implemented, bring one or two large items into the sprint along with two or three smaller items. Some of the programmers can work on the large items, handing them over to testers whenever possible. The remaining programmers can work on the smaller items, ensuring a somewhat smoother flow of work to testers early in the sprint.
While your goal in each sprint should be to do a little bit of everything all the time, some backlog items are complex by nature and will not be completed until near or on the last day of a sprint. To avoid having multiple product backlog items wrapping up the last few days of the sprint, mix the size of the product backlog items you choose to bring into each sprint.
Tags: product backlog, sprint planning
Great post Mike. I think too many people like to preach the ideals of INVEST without really understanding what real-life work can be like sometimes.
Sometimes the effort to take a bigger story and break it into smaller chunks isn’t worth the payoff.
The team I’m working with now manages the backlog in a similar way. Some of our stories are ‘big’ in the sense that 1 story may take the team a few days to complete and there are times near the end of the iteration where team members may not have something to do. They will pair together in those instances but they also like to use this time for working on small improvements whether it be team infrastructure or simple enhancements based on demo feedback.
Our team has a team rule where we will commit to roughly our velocity and whenever possible, pull in smaller improvements when they are blocked or team members are idle. These are treated as our ‘heres-some-stuff-we-can-do-if-we-have-extra-time backlog’
That may be ‘agile blasphemy’ but it works for our team and our PO is pleased with the results.
Hi Mike,
Another way we can look at this live issue is to multiplex. Let’s say the velocity is about x-story points.
- Each sprint has the developers (analysts/ designers/ developers)work on completing the united-tested code for x-story points.
- Meanwhile, each sprint the testers complete testing of x-story points of code which have been completed in the last sprint.
- The developer fix the bugs discovered by the testers in addition to developing the code to be tested next sprint.
- Reduce the sprint length to 2 weeks to reduce waiting time and two have a shippable code every four weeks.
- The last 1-2 sprints before producing the release will be focus on module integration testing, performance testing, customer acceptance scripts and the associated code fixing.
Thanks for raising this subject.
Hi Jason–
Nothing sounds blasphemous to me in what you describe.
Hi Sameh–
If I understand you correctly, you’re describing having the testers (for example) following a partial sprint behind. I certainly experimented with that back in the mid-90s when I began taking an agile approach to projects. But what I (and just about everyone else) learned is that this is a bad idea. There are too many reasons why for me to go into right now (but hopefully others can contribute some). However, I’ll mention that Scrum gets its very name from the idea of a cross-functional team working all together during the sprint/iteration.
Yes, I understand that it is best to have all team working on the same user-stories at the same sprint. This will reduce work-in-progress that tends to lengthen the lead-time to implement a feature.
My reservation is that testing of working code is different kind of skills with different mind-set. By testing, I don’t mean the unit-testing that should be completed by developers, I mean QA activities which can only be executed once the code has been unit tested and integrated by developers.
Till it comes the time we have testing is done on sample of code (as the case with other industries), testing will continue to be challenging. From my experience, testing and associated code fixing take more than 50% of the development effort. If testers follow professional approach for developing test cases during their involvements with the analysts and designers, this probably can reduce their waiting time. Also, the reusable test cases are valuable assets for re-running the testing at future sprints as new features are added.
If testers (QA) are more doing exploratory testing without producing test plan and procedures; then they are bound to wait.
This seems (conceptually) similar to the old ‘trick’ of starting with a jar full of rocks that seems ‘full’, then pouring in smaller gravel that demonstrates how its possible to fill the jar more completely, then repeating the process with finer-grained sand, then finally with water — all demonstrating that even when something seems ‘full’ there is often in fact still room for more, assuming the ‘more’ is small enough to fit into the gaps between the larger items already present.
By selecting variable-sized stories for an iteration, this seems a similar concepts applied to workload allocation (fill the small gaps between larger tasks with smaller tasks that fit the gaps well).
Great idea(s)!
-Steve B.
Hi Steve–
Great comparison to the rocks in a jar story. I’ve heard that story numerous times and never related it to this. Now that you point it out, it’s very clear. Thanks.
My team have recently started to apply this in practice and play stories in order from biggest to smallest. The larger stories are played first with smaller filler stories deferred towards the end.
It’s particularly useful when a story starts slipping and you need the rest of the team to pick up the slack. Playing a number of small stories in the last day or two of the iteration is usually manageable across multiple pairs, whereas playing a single larger story generally isn’t, or at the very least you need to split the story across pairs which can be painful.
Hi Rob–
Good point. You are very right that it will often be much easier for a team to find a way to fit a couple of small stories in on the last day or two.
[...] Cohns post prompted me to blog on what my team has been practicing for the last few [...]
[...] Mix the Sizes of the Product Backlog Items You Commit To [...]
We have just adopted user stories, but have some difficulty with the fact that we have two and sometimes three different coders involved in getting one story done. (one UI developer, one business logic developer and one that is focuing on integration against some third party). I’ve gathered that it is bad practice to split a story horizontally between technical layers, so even though I have three guys this should all be one story. How do you go about passing this story between the developers? We experiment with a kanban board, so even though there is handover between three developers, the story basically stays in the “work” column. Should we just switch names on the task as the underlaying layer is done and the next guy starts working? Usually everyone are to some extent working on the same task at the same time on different layers. Most any examples I find seem to imply that one user story is worked on by one “developer” not taking into account that it may span across layer where no one developer have the required knowledge to complete it.
Any comments appreciated.
Hi Thorbjørn–
I’m pleased to hear you are trying out user stories. I think after a few initial hurdles you’ll find them a good technique.
You are correct that we don’t want to create separate user stories for the different layers of work (e.g., UI, business logic, etc.). One possibility for you might be to write smaller stories. If you had a smaller story (that was still worked on by the 3 individuals you list) then it would move more quickly from an “in process” to “done” state.
Another option, and possibly a better fit from what I can infer from your comment, would be to create specific tasks representing the work of the user story. During sprint planning the team usually takes the one user story and turns it into perhaps 5-10 tasks. If you had a tasks of “Code the UI” and “Create business logic” and “integrate with third party” and “design tests” and “automate tests” that would probably create the right result for you.
You can see this visually a bit at http://www.mountaingoatsoftware.com/scrum/task-boards which shows some task boards. Each row represents a user story and the card in the first column is a user story. Cards in other columns are each tasks.