10

The traditional Waterfall lifecycle includes a specific phase for design and planning. In Scrum there is no big up front design. A small amount of design to conducted when breaking down features into stories, during the sprint planning meeting and during the sprint.

Since sprint planning is time boxed to a few hours, there isn't enough time for the team to decide on technology choices, which responsibilities belong different components deployment and release considerations etc.

Where does design work belong? Should it be conducted prior to sprint planning with details added to stories or tasks? Or should there be an additional design meeting post sprint planning?

LazyCoder
  • 607
  • 4
  • 11
  • 1
    see [How do you deal with design in Scrum?](https://softwareengineering.stackexchange.com/q/36562/31260) – gnat Jun 24 '17 at 06:56
  • 4
    Possible duplicate of [How is architectural design done in an agile environment?](https://softwareengineering.stackexchange.com/questions/165971/how-is-architectural-design-done-in-an-agile-environment) – gnat Jun 24 '17 at 06:58
  • 1
    You need to define "design". It's not clear if you're talking about system architecture, UX, UI, requirements gathering, or what. "design and planning" is what you reference in the context of waterfall and that's a HUGE set of stuff. – RibaldEddie Jun 25 '17 at 02:13
  • Architecture and design should evolve as the team decides how they are going to address the requirements on the backlog. This activity should be ongoing. It is ok for individual team members to spend time thinking about these things in advance, but the team should discuss potential solutions during backlog refinement meetings to build consensus and generate estimates. If you are not already, try adding a 2-3 backlog refinement meetings of 1-2 hours in length to your sprints and use them as a time for team architecture and design discussions regarding upcoming backlog items. – treefiddy Sep 21 '19 at 14:54

6 Answers6

10

Design should be planned for, either as enough extra story points per story or as a separate story. And you should still have designers on your team who own and monitor the design.

The trouble is that design represents "no business value" and pure user stories will typically be dumped onto "the team" which is this blob of developers that focusses on workable software rather than maintainable software. So with the introduction of scrum, conscious design often ceases to exist. For larger, long running products this is a desaster waiting to happen of course. It will be a silent one though, development time and the number of bugs coming back will just gradually go up. And no one will regard this as worrying, we will just do more testing and feel good about it. It is not a coincidence that testing has grown into a big thing lately, also in run-off-the-mill software projects.

Fortunately, today we also have a fancy name for this: "technical debt". It is a great name because it does not sound like a problem to anyone but the development team. It implies it is their fault too, the techies should pay for it, not the business. It is their problem.

And in all fairness, it really is. The development team must make sure they do design. They are self organising and must be strong enough to reserve the resourses to do what is necessary. They commit to a planning they make themselves. There will be pressure to move ahead with features but it remains their responsibility to think things through and to have people who are responsible and accountable for this. Scrum does make it harder to maintain these basics.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
  • This answer sort of feels all over the place. The first paragraph contradicts the last. – RibaldEddie Jun 25 '17 at 02:08
  • @RibaldEddie I addressed different factors but the first and last parts are the same. The last just stresses it is the team's responsibility now (to make sure design gets proper attention). – Martin Maat Jun 25 '17 at 07:45
  • I think the key to this answer is that Stories in Agile should not include implementation details, they should state what the subject wants and how to verify it. This way you could technically have a separate story, or a spike or subtask, to do the architecture for that story. – Steve Sep 02 '21 at 17:47
7

Robert C. Martin had a talk about that you can find on youtube:

The land Scrum forgot

There he adresses this common issue that in Scrum architecture and design is never mentioned so it is up to the team to identify what architecture and desiogn should mean within the project.

My personal opinion is that you should have one instance in the team to be responsible for architecture and design. The contract should be: The architect decides how these subjects are adressed. On the other side he should not be able to escape resulting questions that came out of his decisions.

In my current project we are currently facing several issues, that can mainly be broken down to concept diversification and disharmozied code base beside implementions that completely ignores the architecture instead of extending it in a useful way.

The point is: If you cannot find a consense about the best architecture to the given requirements within the team, you cannot expect the team doing a good job. This also true for issues of code quality. A democratic way of solving this problem may be a way if the understanding only differs in some little points. But if you have essential discussions that do not lead to a solution you better put someone in the position to decide.

oopexpert
  • 769
  • 4
  • 7
5

Where does design work belong?

Either before the first sprint, or on the first sprint, and possibly in every subsequent sprint. Some teams will have a period of time before the first sprint where some of these decisions are made. If the decisions aren't made before the first sprint, then you must do at least some of the design and archtecture work in the first sprint. As the project progresses through the sprints there will come opportunities for additional design and architecture tasks. The extent depends on the scope and complexity of the product being built.

I think it's perfectly valid during any sprint planning session to say something like "we don't have enough information about how we are going to architect this, so our first story (or task) needs to be to come up with the architecture."

The whole point of scrum is to have teams that are empowered to make decisions on how to build a product. If part of the process of building the product involves deciding on architecture, that is a perfectly fine activity for any sprint.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
  • 3
    Design can't possibly be restricted to a particular sprint in an agile context because there will likely be redesign needed of particular components as the project unfolds. The assumptions that were useful in sprint 2 may need to be re understood by sprint 12. Recall that the agile manifesto and Scrum both reference indefinite _sustainable_ development as a goal. So design should be a constant activity by the team. – RibaldEddie Jun 25 '17 at 03:14
  • @RibaldEddie: agreed. Design is to some extent on-going through every sprint. I'll try to reword my answer to better reflect that. – Bryan Oakley Jun 25 '17 at 03:47
1

there isn't enough time for the team to decide on technology choices, which responsibilities belong different components deployment and release considerations etc

Most of this is dealt with in a 'Sprint 0' or is just inherent to the team. You expect build servers and environments to be in place before the project starts.

Just as if you are a team of c# web developers, you known you will be writing a asp.net web site backed by MSSQL

Scrum is focused on getting results quickly. So which javascript framework, or database is the best isn't important. Don't waste time thinking about them.

Choose the thing that is quickest to implement every. single. time.

If the product is a success, then in a few years you will maybe have another project to change one of the technologies to a cheaper version.

Ewan
  • 70,664
  • 5
  • 76
  • 161
1

There are activities that need to be performed before the teams actually goes Sprinting. Team is assembled, tools are procured, budget is secured, estimation is done, draft vision is created, architecture is decide.

The idea is to prepare just enough and to not go for weeks and month before actually test your hypothesis.

Therefore, take time to setup and ask the very first questions then work out the unknowns alliteratively in Sprints.

I suggest to avoid calling the preparation period Sprint Zero, or Hardening Sprint etc.

Ionut-Adrian Bejenaru
  • 11
  • 1
0

Design work prior to planning meeting is not preferable as the team won't have sufficient inputs because the story hasn't been broken down. The planning meeting can be used for breaking down the features and estimation. Later the team should be given time for analysis and re-estimating the story after which a meeting should be scheduled for design work.

Nishanth Menon
  • 61
  • 2
  • 4
    This does not make sense to me. Design is just work that can be estimated in the same planning sessions as the features themselves. – Martin Maat Jun 24 '17 at 21:00