A good ScrumMaster will continually nudge a team toward adopting improved technical practices that help them learn how to overlap their work. If a team doesn’t learn effective ways to do this, team members may settle on a less desirable approach: activity-specific sprints. An activity-specific sprint is as bad a practice as it would be an acronym. In this approach, the team decides to use one sprint for analysis and design, a second sprint for coding, and a third for testing. The team is split in thirds, with the analysts working one sprint ahead of the programmers and the testers working one sprint behind them.
This can be a very alluring approach. Not only does it seemingly solve the problem of how to overlap work but it also allows each type of specialist to work mostly with others of their own kind, which many may prefer until they become used to the close collaboration of a Scrum team. Unfortunately, the same disadvantages apply to activity-specific sprints as apply to activity-specific teams: too many hand-offs and a lack of whole-team responsibility.
One of the biggest problems with activity-specific sprints is that they create what are known as finish-to-start relationships. In a finish-to-start relationship, one task must finish before the next can start. For example, a Gantt chart on a sequential project may show that analysis must finish before coding can start and that coding must finish before testing can start. Good Scrum teams learn that this is not true; many activities can be overlapped. What is important is not when tasks start but when they finish. Coding cannot finish until analysis finishes and testing cannot finish until coding finishes. These are known as finish-to-finish relationships and are reinforced by Scrum’s sprint mechanism. All work is done at the end of the sprint, or it is returned to the product backlog.
With a little experience, most teams are able to see how to overlap some types of work and create finish-to-finish relationships between them. Teams easily find ways to overlap discussions of what users need and programming. They also soon find ways to overlap programming and testing. These activities lend themselves to iterative and incremental approaches: Get a few details from the users about what they need and then build a little of it; build a little and then test what you’ve built. Other activities, though, do not appear at first to be as amenable to an iterative, incremental approach. User experience design, database design, and architecture are often cited as work that needs to be done up front because the work must be viewed holistically. I argue that we should think holistically but work iteratively toward solutions. All sprint activities can and should overlap.
For specific guidance on how to overlap work in a sprint, see Chapter 14, “Sprints,” in Succeeding with Agile.
Tags: teamwork
To get in this direction I think we need to hone our ability to “slice the cheese in another direction”, i e to cut thinner and thinner slices of functionality when defining a story. And those slices should still each form a free-standing business value.
The most extreme gang I have seen in this regard (EnergizedWork) used a “login window” story as an example. To them a “login window” was not one story but four sub-stories! One: a login button with preconfigured username/password. Two: a field with username. Three: a username/password field pair. Four: error message for failed login. Each “substory” was implemented/tested/accepted, and each would take a half-day for a programmer-pair.
Needless to say, it is meaningless to do task-breakdown and task-level estimation if we are able to slice our stories this thin. So we can save a lot of design decisions to “latest responsible moment” very late into progress.
Also imagine what such an ability will do to the top (or “shortlist” part) of your backlog – those stories on top will definitely be ready for development.
I think this is probably the area where we as a business need to improve most at the moment.
Hi Dan–
Interesting story. Thanks for sharing it. There is a cost to breaking stories down so it’s important to always remember that. In this example we could have had a two-day story or four half-day stories. I have coached teams to do this both ways. If a team finds that things are working well for them with whichever of these approaches they are using now, switching can often be valuable.
Thanks for another good post.
What you are describing here, the activity-specific sprints or teams, seems very similar to how RUP projects are run – iterative, with its clearly defined roles and handovers of artifacts. However, in the initial phase of a project (what RUP calls the Inception and to a certain degree, also Elaboration), how can one avoid activity-specific sprints, if we are allowed to use Scrum at all?
Hmm… guess what I’m shooting at here, is how to use Scrum in pre-development… any suggestive reading?
Hi,
I wonder how idea of analysis overlapping matches with latest Jeff Sutherland’s condition to become hyperproductive team which is a “ready” state of the story.
Just to recap story is in a “ready” state whenever all acceptance criteria and details are known. It’s not a step back towards upfront analysis on the project scale but on story.
Those two seem to be coming in the way especially when product owner team is different to development team.
Hi Ådne–
Since Scrum is a general-purpose project management framework, I think it can be used for any project. This includes what I often call the “project-before-the-project,” which refers to some period of time an organization might invest before deciding to undertake a full development effort. This project might include writing a high-level product backlog, doing some rough estimating to determining a likely range of target release date, competitive analysis, or more.
Hi Alex–
I’ve never understood Jeff’s statements that a product backlog item should be fully understood before starting a sprint. What I coach teams to target is having a backlog item understood in *just-enough* detail and just in time. At the end of a sprint, I want the team to say, “Wow, I’m glad we started that sprint with that user story as well understood as we did. If we started with less, we couldn’t have finished it. If we’d started with more understanding of it, that could have been wasted effort.”
I wrote an article on this subject called Writing the Product Backlog Just in Time and Just Enough.
I agree that “Analysis in Sprint 1, Design in Sprint 2, Implementation in Sprint 3″ isn’t a good approach but in practice features need to be specified at _adequate_ detail before it is reasonable to start implementing them.
In theory, it is great if a team can get some story or feature from vague one sentence summary level to fully implemented, tested and approved state within one short 1-2 week iteration.
However, in real life customer business support solution development this rarely happens (at least in the projects I have seen). Or if it does, stories are typically _very_ small and there is ultra high bandwidth communication between the development team and highly available customer/end user representatives. Too many tiny stories can be a big problem as well.
For example if you are building a space shuttle control system for NASA it is sheer madness to document “requirements” using some one sentence user stories (on post-it notes
) and start writing code right away based on very vague definitions. Especially if the team also thinks that “architecture just happens” – don’t design anything up front.
The complexity of the system domain, team structure, size and skill level, geographical distribution of the team, availability of the customer domain experts, number of other suppliers in the programme/project, technical complexity, amount of interfaces to other systems, law, pricing model (esp. fixed price bids) etc. have a significant impact on how the project should be and how it can be run.
In my opinion some “agilists” have needlessly labeled the term “up front” as a four letter word – something you should avoid at all costs. Encouraging teams to dive straight into coding with very vague requirements (CHAOS reports anyone?) can lead easily to code-and-fix type development, massive refactoring/rework and possibly even architectural meltdown.
Poorly executed “agile” project can lead to very high cost of change and poor end result. Also very small stories done “just in time” manner can make it difficult to see the big picture.
The real goal is to minimize the total cost of development, cost of change and of course the quality of the end result.
Coding is not the only way to get rapid feedback. Customers also understand UI prototypes and even technical specs. Despite popular claims, most of them are not idiots who don’t know what they want until they see it running on their screen as real code.
The key thing is to do enough up front analysis and design, light-weight prototyping and build just enough of the architectural core (walking skeleton) incrementally. Not all or nothing – enough. What is enough depends on the context. RUP has been widely misunderstood but I think it really captures the _core_ ideas very well (if you just ignore all the workflows, roles, detailed descriptions etc noise).
I believe in iterative and incremental development. I think Scrum is a good framework. Hybrid RUP + Scrum + XP works well as a combination when used properly. But Scrum is not a silver bullet and can lead into much _worse_ results than even waterfallish approach if the context and limitations are not taken into account when designing the development process.
PS. I agree with Jeff that Product Backlog items should be fully understood before taking them into the Sprint. “If you don’t know how to get a story out of the iteration, don’t let it in.” is a good motto.
Hi Mike,
Thanks a lot for a fast reply.
Perhaps I misunderstood Jeff’s idea he presented during Munich Scrum Gathering last year of ready state stories. However if you have access to his presentation from the gathering you may take a look on slide 50 with checklist of several items in order to mature story before shove it to sprint. Last parts are quite detailed though I got impression not so much space should be left for analyzing during the sprint. Just to mention “Product requirements developed” or, which me surprises me more, “Technical design drafted (No uncertainties)” as a examples from the ready checklist.
Hi Jarkko–
I agree with almost everything you say. In fact the only thing I disagree is your last paragraph where you say that “product backlog items should be fully understood before taking them into the sprint.” If this were true then an analyst (who presumably figured those backlog items out) would never, under any circumstances, have a need to talk with the rest of the team during the sprint. This completely contradicts what you said two paragraphs above that: “The key thing is to do enough up front analysis and design, light-weight prototyping and build just enough of the architectural core incrementally.” And this is what I’ve been saying all along–do just enough upfront thinking (and do it just-in-time; in general we don’t want to think “too far” ahead where “too far” can be defined by the domain of the project).
Hi Alex–
You’re right: with a 23-item checklist of things to be performed before a story can be brought into a sprint, there is no real room left for analysis during a sprint. And the “no uncertainties” item is the biggest problem on there.
My issue with all of this would be what makes this approach (all analysis done in its own sprint (or two) before anyone else starts) any different from an approach that says all coding is done before a story is handed to the testers. Philosophically I can see no reason why one would be OK and the other not. Scrum gets its very name from the idea of a cross-functional team working together. This approach goes quite against that.
Hi Mike,
Looks like it’s about right balance and I like your idea of “just-in-time and just-enough”. I work mainly for CMS portal enhancements projects and in most cases developers prefer to have some mock-ups or page designs before they estimate backlog for release or take the story in. As a result we work with them stapled to cards. Then analyst, in most cases along with HTML developer work on details.
However we still need to work on overlapping (your previous post suggests a smaller story solution) as it turns out for some of the stories that CMS or Java developers wait for clarification to be done by analyst. That’s of course waste.
Nice post Mike. I have seen this tendency to have requirements working two sprints ahead, architecture working one sprint ahead and testing working one sprint behind. I think there is something more dangerous than the finish-to-start relationships that you talk about. The main problem is that the process you describe decreases communication and builds up walls between traditional disciplines. (You hit on this with your comment on the “lack of whole-team responsibility.)
By the way, I really liked Jarkko’s comment. Websites are often used to illustrate agile techniques. While website development has its challenges, there are many other types of projects that are far more complex. Sometimes with these more complex projects, applying some of the very basic agile techniques can be a challenge (like simply identifying user stories that provide business value).
Hi Alex–
Your example of the mockup stapled to a card is perfect. When I train on this topic I usually hold up an index card and then hold a few pieces of paper behind it and say that “sometimes we staple additional information to the story card. It can be a screen mockup, a workflow diagrammed in Visio, etc.” I give examples of mathematical algorithms worked out in Mathematica being stapled to the card for the team to convert into Java code and so on.
WIth the user interface example, I make the point that what is stapled to the card does not need to be (and should not be) pixel perfect. The designer could attach a screen design saying, “Make it like this except for this little region here on the screen. I’m still working with some users to figure out how best to do that. But I can do that during the sprint and you’ve got plenty to get started on the rest of this.”
Hi Terry–
Websites make great *first examples.* Even if someone has never coded a website, they’ve used enough to have an idea of what’s involved (certainly by now!) But, for an argument to be compelling into broader applications, it does need to go beyond, “Suppose you’re building an eCommerce site…”
In my view “Just enough” is very dependant on how cheap a system is to change should an analyst change his or her mind mid iteration, and how much slack a schedule has to accommodate this work. Developing production ready working software to explore options can be an expensive activity. I’m not denying that learning may have occurred during this exploration, but there are often cheaper ways than coding to explore and home in on a good solution.
My team work with analysis occurring one iteration head of development and it works for us. However due to the nature of the work, developers often assist with the analysis effort using spikes, prototypes, etc before we commit to an actual approach that is developed as production ready software in the subsequent iteration. So in our context “just enough” for a complex story could be several days analysis and several days prototyping effort. Just enough might not be as small as you might think.
Hi Rob–
You might be misinterpreting what I consider “just enough.” You say your team might do analysis for several days. I’ve worked with a team that was fantastic that had to do up to 6 months of analysis before programmers could start. (This was a bioinformatics company and the analysts were dual-Ph.D.s in math and genetics. They would prototype an algorithm in Mathematica and then hand it to the programmers. The prototyping though was really lots of deep thinking to find a new way of looking at data that would be meaningful in the product.)
This is why I never define how long “just enough” is. It depends completely on the domain, application, team, and other contextual factors. What I don’t want to do though is have a company say “all backlog items are analyzed six months in advance” just because some need to me. We don’t want to institutionalize things like that.
Hi Mike,
I was trying to make the point, probably poorly that “just enough analysis” might take quite a bit more time to perform than what might be typically assumed given a story is commonly described as being quite lightweight (i.e. something like a story card, some acceptance criteria and maybe a UI design). I completely agree that “just enough” is very dependent on the context as you describe, and also that process shouldn’t trump interactions within the team.
My team have settled on performing the analysis one iteration ahead, which I think works quite well for the majority of our story development. I think there is also something to be said for having a degree of predictability and rhythm to a process.
I’m finding thinking of activity-specific sprints as bad practice a little difficult to digest at the moment, probably because a) this is what my team currently do and b) there are far worse ways to develop software in my view. Time to ponder and reflect I think.
Completely understandable, Rob.
What I’d suggest is picking a time when everyone feels up for an experiment and see if you can bring more cross-discipline work into the sprint and see what that does to communication. My usual recommendation (for any experiment like this) is to try it for two sprints before making a decision about how it’s working. By all means, do a retrospective after the first and see if you can think of tweaks to what you tried but don’t give up after one sprint. A lot of changes feel weird in the first sprint doing them. Good luck.
I think the activity-based sprints approach resembles Water-fall. The hand-offs from skill set to another is done across the sprints.
The traditional V-model parallels the QA activities with those of analysis and development. QA is for defects prevention rather than after the fact quality control. Having this in mind, I think we can blend QA, developers and analysts to work on same user stories in the same sprint.
QA can work in making conditions of satisfaction of the user stories more comprehensive. This itself help to gain better understanding of the requirements and better estimation for sizing.
Human mind tend to think sequentially. The approach of Inter-leaving work and concurrency on same story is not easy to visualize and cannot be managed by traditional management.
Thanks Mike for raising this interesting subject.
Hi Sameh–
You’re absolutely right about the human brain. I’m no cognitive scientist but a sequential approach to work seems to fit our brains. I want to think about what needs to be done, then I want to design a plan for doing it, and then I’ll do it. If our brains work this way, it’s only natural that we would have for years tried to force a sequential process onto software development.
Hi Mike:
I am experiencing the exact same issue as a SM for a product that touches all others in the enterprize. Because we don’t have a pre-defined EA, I’ve been advocating starting small and progressively elaborating. The problem is – the team vehemently disagrees on the definition of “small”
In other words, it’s quite difficult to define what just enough means. And it certainly doesn’t help that we’re starting from stratch and have time constraints.
I certainly don’t have the technical aptitude in that area to define it for the team, so the argument continues.
As much as I don’t want to, I’m considering EUP (Enterprise Unified Process) – a spin on UP, as a potential solution. But I feel like this step will regress us into Waterfall…sigh.