The origin of Scrum lies in software engineering where visual appeal didn't really matter. When we mention software design, most people will think about the technical design and not the visual look of the software. On the other hand, website development is a lot about visual communication. Therefor when we mention website design, most people will in contrast think about the visual aspects.
When we mention website design, most people will in contrast think about the visual aspects.
Here lies the challenge when Scrum is applied at website development. A product backlog is not seen sufficient when the product owners want to describe the visual communication requirements. As a solution, they want graphic designers to design the website upfront. But this complicate things even more, because a graphic design implicitly requires functional solutions. They fall unconsciously in to the trap of "Big Design Up Front".
If we visualize the needed final product as this knot, it is maybe easier why it is difficult to formulate a solution and why a graphic design will only be misleading by pointing in the the wrong direction. As it is visible in the picture, it is really hard to formulate (for a non-expert) what this shape looks like and how it should be constructed. (This is only a trefoil knot. If it is not a prime knot, things will be even more difficult.)
For a moment we are going to think in general abstractions: In the problem domain, things are very fuzzy. The most challenging aspects is that the solution and problem entities are adaptive. When you change one part of the solution or the problem, other parts of the system are also effected. This makes it almost impossible to come up with a whole design solution for the whole problem at once. (This would also imply that the problem is definitively defined.)
By creating a graphic design everything can look very logical and plausible. It is even looking pretty and appealing. There is not really a way to test if it is really going to work. Neither there is a way to formulate the design unambiguously. The design is ready and nice-looking, it only needs to be build!
The intentions of assigning people to discover and explore the project is good and well-meant. But the unintended consequences of design are really troublesome. At the beginning of the sprint planning, there is a perceived product solution (which is not going to work) and the development team has just beginning to think in the problem domain. The team can do two things:
- Try to explain that is wrong to assume there is already a sollution. But this will be difficult, because the graphic design looks very tangible and acceptable.
- Just try to build the product and execute the plan. This will especially happen with an inexperienced team because they will not be able to judge the design and will be enthusiastic by the proposed solution.
" At the beginning of the sprint planning, there is a perceived product solution and the development team has just beginning to think in the problem domain. "
The biggest flaw of this process is that it assumes that design is difficult to predict and requires expensive and creative people, and that the actual development can be done by lower skilled people. This is a real wrong way to think about software development with a lot of side effects: Martin Fowler explained it extensively.
How much can be designed before a sprint?
It is impossible to generalize, how much in advance design is allowed or needed. The general answer is: "just enough". But this is off course not unambiguous. The rule of thumb is: never more than 1 week or not more then 10% of the sprint time. So, if a sprint time of 300 hours is used, the design phase shouldn't take more than 30 hours.
" If a sprint time of 300 hours is used, the design phase shouldn't take more than 30 hours. "
A general, long term vision and strategy is indispensable but this needs to be expressed in business terms and business value and shouldn't be expressed in user interfaces, graphic designs etc. The solution and design should be made by the team self. If the team is not able to design the solution, they will definitely not be able to build a working product anyway. Let alone debug it. ;)
Emergent architecture is already often discussed in the Scrum community and how Scrum can lead to technical debt. The conclusion is that solid technical practices are really essential and that Scrum alone is not enough to be successful.
Product backlog is the only artifact that should be created. All the other artifacts like graphic design, architectural design or interaction design should be developed within the sprint, by the development team. This is the only way that there can't be a gap between design and realization.