The agile process favors an incremental, just-in-time approach to design. As such, Scrum projects do not have an upfront analysis or design phase; all work occurs within the repeated cycle of sprints. This does not mean, however, that design on a Scrum project is not intentional. An intentional design process is one in which the design is guided through deliberate, conscious decision making.

The difference on a Scrum project is not that intentional design is thrown out, but that it is done (like everything else on a Scrum project) incrementally. Scrum teams acknowledge that as nice as it might be to make all design decisions up front, doing so is impossible. This means that on a Scrum project, design is both intentional and emergent. The design emerges because there is no up-front design phase (even though there are design activities during all sprints). Design is intentional because product backlog items are deliberately chosen with an eye toward pushing the design in different directions at different times.

As an example of how the product backlog items can be sequenced to influence the architecture of the system, consider a workflow system I worked on. The system supported a fund-raising company that produced specialized T-shirts and similar products. School-age children would go door to door selling these items. The sales revenue would be split between the company and the organization the kids represented, such as a school, sports team, or other group.

For each sale, the kid would complete a form and send it to the company, where it was scanned, sent through an optical character recognition (OCR) process, and converted into an order. To keep shipping costs down, orders from the same organization were batched together and sent back to the organization, after which the kids would hand-deliver the items.

Our software handled the entire process—from when the paper was received by the company until the shipment went out the door. Kids have notoriously bad writing and are bad spellers, so our system had to do more than just scan forms and prepare packing lists. There were various levels of validation depending upon how accurately we thought each order form had been read.

Some forms were routed to human data-entry clerks who were presented the scanned form on one side of the screen, the system’s interpretation on the right, and an additional space to make corrections. Because thousands of shirts were processed on the busiest days, this process needed to be as automated as possible. I worked with the product owner, Steve, to write the product backlog.

After that, I met with the development team to discuss which areas of the system were the highest risk or we were the most uncertain about how to develop. We decided that our first sprint would focus on getting a high-quality document to run through the system from end to end. It would be scanned, go through OCR, and generate a packing list. We would bypass optional steps such as deskewing crooked pages, despeckling pages, and so on but would prove that the workflow could be completed from start to finish.

This wasn’t highly valuable but it was something that needed to be done, and it let the developers test out the general architecture. After we accomplished this, we had a basic database in place and could move documents from state to state, triggering the correct workflow steps. Next the developers asked the product owner if they could work on the part of the system that would display a scanned document to a human who would be able to override the scanned and interpreted values. This was chosen as the second architectural goal of the project for three reasons:

It was a manual step, making it different from the workflow steps handled already.

Getting the user interface right was critical. With the volume of documents flowing through this system, saving seconds was important. We wanted to get early feedback from users to allow time to iterate on usability.

After this feature was added, users could start processing shirt orders.

The project continued in this way for a few months and was ultimately tremendously successful, meeting all of the prerelease targets for reliability and throughput. A key to the success was that the product owner and technical personnel worked together to sequence the work. The closest the team got to a design phase was the first afternoon in the conference room when we identified risky areas and dark corners and decided which one we wanted to tackle first.

From there the design emerged sprint by sprint, yet was intentionally guided by which product backlog items were selected to illuminate the dark corners and risks of the project. Succeeding with Agile goes into much more detail on agile design, including how the roles of architect and user experience designer change with Scrum, the concept of emergent design, and how teams work together and with the product owner to deliver increments of functionality that guide the design of the final product.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

Thanks for sharing some effective ideas about Agile. The Agile Design which you have provided is very helpful.I also like to share with you some facts about Agile from http://www.scrumstudy.com/blog...

Posted by Joseph mo on 2016-01-13 03:04:27

Hi Jonathan--
I'd guess I'd add that Big Backlog Up Front is worse because backlog precedes design so it means we've done something even further ahead than necessary.
So, while I'm a fan of a detailed backlog upfront (which would make it big, since it's detailed), I do like having the "Big Picture Upfront." I'd equate that to your "have a vision upfront," which I think is essential but is easily overdone by some teams.Posted by Mike Cohn on 2012-12-30 22:10:58

Big Design up front, or Big Backlog up front is pretty much the same thing. BBUF is worse because it's just a list of text and no picture to explain it.
Just in Time design for everything actually works in software, and works really well when there is a holistic idea of the larger system that these 'JIT' bits can comply with.
So, have a vision up front, but don't formalize it. Give some compliance guidelines in a quality model (aka non-functional story backlog) and let the design decisions during the iterations do the formalization when it is needed.
Posted by Jonathan Seller on 2012-12-28 13:35:13

Hi Dan--
Excellent point. Thank you for finding another way to say that some thinking ahead is OK. Just because Scrum doesn't have phases (such as a "design phase," as some seem to want to add to it) does not mean we don't think ahead. I think, for example, that I have now made the point in three books that I want a "complete" product backlog to exist before the project starts or at least before it gets going in full swing.
(To avoid the attacks on that comment, note that "complete" means that the scope of the product is identified but perhaps at a very, very high level with epics, which are great big stories.)
Having a product backlog that describes the system in entirety (at as high a level as can be given factors such as the complexity of domain, criticality of the system, etc.) is one way of thinking ahead. There is nothing wrong with this. But good teams are careful to make sure they are not thinking too far in advance of doing.Posted by Mike Cohn on 2009-12-06 13:08:43

Hi Mustafa--
Great story. You sound like an ideal product owner to work with.Posted by Mike Cohn on 2009-12-06 13:03:59

I think Google Search was not the best example. Instead, consider creating a competitive J2EE application server. Going a feature-set or sprint at a time will very likely have you re-architecting and tossing code over and over... the fact is, you can not deliver reasonable customer value in a few weeks. It is complex infrastucture product and you have nothing until you clear several large hurdles. I think trying to deliver a Unix/Linux style O/S, seeking to retain the gammut of compatibility, but without directly taking advantage of an existing code base, would also be such an endeavor. Or a ground-breaking ANSI SQL-compliant database engine.
You would still figure out how to create reasonable iterations, experiments, and so on... But I definitely believe that some products defy simple evolutionary development. Embracing change is something to include via solid design and architecture - but some product categories have a well-establushed stable and very large set of standards to comply with.
There is an awful lot in google that took more then a modest amount of thought... wheels within wheels - design leverage - innovation - does not come off the shelf. There were a lot of cell phones before the iPhone came along... you could see the "commodity thinking" in them; interesting products come from breaking new ground - something that does not happen easily in a sprint. Sprints are commodity execution after you have enough foundation to proceed. If you are just making a web site... good lord, just get started. If you are writing the Google ChromeOS... well, I wonder how they are doing that.Posted by Jeff Smith on 2009-12-06 07:18:27

This is a very good parallel to where TDD is sometimes misinterpreted as "no thinking ahead". It is not; it is thinking far ahead, but only implementing little at a time.
In the same way; in agile/Scrum you should think a lot about design to know your options, but only implement what is motivated by your current needs.
If you *do* select and implement a choice (of design) before it is strictly motivated by your current needs, you do not keep your options open. You close them.Posted by Dan Bergh Johnsson on 2009-12-05 15:34:37

Hi Mike,
We just had a similar situation happen on our team this sprint. The epic we were working on was complex. It involved increasing data density as we zoomed in on a dataset.
The first instinct of some of the team members was to go for a 'research and design story' because of the complexity of the epic. Without it, they felt they could not decompose that epic into smaller stories - fearing rework, or mistakes.
As the Product Owner, I pushed back and said "I need something that I can see. Give me something. It doesn't need to be perfect. The rest we'll figure out later."
After some discussion, the team was able to settle on hooking the zoom function straight into a query, and adding a 'smart interval' where it would automatically figure out the granularity it needed to query every time.
So when this is done, I can zoom and see more granularity? Yes. Perfect!
"It will be clunky," one team member warned. It didn't matter.
Would it be clunky? Of course. This is the first sprint. The team, as brilliant as they are, were already anticipating all the wasted queries, caching possibilities and other potential performance enhancements.
Once this is done, I am sure it will 'illuminate the dark corners' of the epic, and create stories we would not have been able to anticipate, regardless of up front design.
I can hardly wait for the two weeks to be over!Posted by Mustafa Al-mosawi on 2009-12-05 07:47:59

Great post and great discussion.
Regarding the risk discussion (Rajiv):
Since the blog is Succeeding with Agile (not just Scrum), it's worth considering other Agile approaches (either separately or a hybrid). There are other IID methods more specific with architecturally risky/complex requirements, that still drive value every iteration. Larman discusses lots of options in Agile Project Management (and a lot on the UP in Applying UML and Patterns). I just purchased Succeeding with Agile so I'm looking forward to seeing those thoughts.
I love Scrum (just applied for CSP) - but I'm still not convinced it's "the" agile method for all projects, based on the nature of the system, team, business environment, customer/client, experience of your team and PM/Lead, etc.
Hope this helps.Posted by Matthew Hughes on 2009-12-05 05:22:21

Doesn't the fact that you can do a risk assessment on the backlog somewhat necessitate that you have some understanding of the architectural baseline? I am no way suggesting big up front design... just a high level assessment of what we think the system will include and what it won't.Posted by Mike Cottmeyer on 2009-12-04 15:10:19

Rajiv--
This topic is covered more completely in a number of sections of the Succeeding with Agile book including some examples, so you may want to look there.
But, the idea is that even on a sequential product the architect or designer doesn't sit around and never touch his or her compiler. The good architect/designer will think about something risky, code a bit to prove it out, then think some more, code some. In a sequential process, this code isn't made "potentially shippable" but it could be and this is the same cycle I'm referring to it. Intentionally pick a part of the system that needs to be thought about and then design/code/test it. Then as new concerns emerge, pick the next part and repeat.
And of course some design occurs first--it may be nanoseconds on something trivial but no one sits down to the compiler and just starts typing. The goal should be though to get the cycle of thinking/doing as short as possible.
As for Google search do you think whatever design they did 10 years ago accommodates everything on the web today? I suspect the application has emerged as new challenges have arisen, just like any system needs to.Posted by Mike Cohn on 2009-12-04 12:03:44

Hi Robert--
While a team could have a "design sprint" I would be very opposed to it. I'd want them to always delivery *some* tangible piece of working code during the sprint. However, the team could spend say 90% of the sprint designing and 10% coding and testing to prove out that design with something that works.Posted by Mike Cohn on 2009-12-04 11:58:30

Mike,
This is one part of the Scrum that I find most difficult to reconcile with. I do understand (at least I think I do :)) how and why you don't need to do an upfront complete design and need to increment it as you go by.
But I am hesitant to admit that complex applications (Google search engine? NASA send-to-moon software etc) can be architect-ed\designed beginning with the first sprint.
IMHO- you have to spend some time architect-ing and doing *some* high level design so that at least the road-map is clear. Now how high level would that design be or how much time you will spend is subjective and subject to your waterfall-free-clear conscience :)
Also I am not sure if what Robert D said in his comments goes with your post. research sprints is what we call sprint zero- right? It is meant to to establish foundation for upcoming sprints. Design sprint is - I think- contrary to what you said. But then maybe I got it all wrongPosted by Rajiv on 2009-12-04 10:58:29

Paragraph 2 says it all for me. Typically when people hear "no upfront design" they believe that there are no design phases at all. As you point out this isn't true. This doesn't preclude us from having research sprints,design sprints, or breaking design into many sprints and then connecting it with code.Posted by Robert Dempsey on 2009-12-04 09:10:41