User story contains a design task that generates other tasks

Question

I have some user stories that have little tasks on basic design with highest priority. This tasks will lead to a conversation about the basic design of the user story and will generate other tasks for the user story. So, how would you handle this?

I have been told that the design should be done in the sprint for each user story but this would change the sprint backlog because it will generate new tasks derived from the created design what is not good.

One option would be just to add a full iteration where just design (just the necessary not the whole) is done and will generate tasks for the next iteration. But I guess this is not the right way to do it.

Could you comment how you solve this?

Answer 1

I have been told that the design should be done in the sprint for each user story

Correct. Implementing a story as part of a sprint includes doing whatever design activities the team considers are required to accomplish the sprint goal (assuming that it's conducive to delivering working software; i.e. don't just do design, also work on implementation.)

but this would change the sprint backlog because it will generate new tasks derived from the created design what is not good.

The development team is in full control of the sprint backlog, and they can add or remove tasks as they see fit, at any time. What Scrum doesn't allow is for people outside the technical team (Product Owner, stakeholders, etc.) to change the composition of the sprint backlog once the sprint is underway.

That being said, the team should keep an eye on how much work they are adding to the sprint backlog, and whether that will still allow them to reach the sprint goal and keep their initial commitment. They should also be careful not to introduce completely new stories in the sprint backlog: adding new tasks that clarify the original intent, or new work that is discovered as part of doing the committed work is fine, but adding completely new stories is not.

One option would be just to add a full iteration where just design (just the necesary not a whole) is done and will generate taks for the next iteration.

Normally, you should try hard to avoid having "just design" iterations. Try simplifying the story scope, building something smaller, less sophisticated, but that gives a tangible result (in the form of real, running software.) Use that as an opportunity for learning, to identify new items for the backlog to be scheduled for future iterations.

Answer 2

Sprint Backlog is created and managed by the development team. According to the Scrum framework, generally nothing goes from the product backlog into the sprint backlog once a sprint has started. The whole concept of sprint estimation and team velocity depends on this rule. If the sprint backlog keeps on changing and is a moving target then the team may not be able to meet the sprint goal and may not get a measure of team's velocity. However, as the stories are being worked on during a sprint, the team may get more clarity/information on the stories. In this case, the team may decide to add/remove tasks from the sprint backlog if it helps them in completing the sprint goal. For example, a minor UI validation task for an existing sprint story can be added to the sprint but adding a task to change whole UI flow may jeopardize sprint delivery. If the Product Owner thinks that, after discovering this new task, there is no point in continuing with the sprint then he/she may terminate the current sprint and start a new sprint with the top priority items from the product backlog.

Feedback and conversations may generate new stories. By default all new stories go into the product backlog. The product owner is responsible to regularly prioritize the backlog. From which a sprint backlog is populated.

You are correct that design should be part of the user story and should be done in the same sprint. However, its not such that once designed can never change. During sprint review/demo there can be feedback/changes on the existing design, add that to the product backlog and handle it based on the priority set by the PO.

Answer 3

One path that can be followed is to do a research spike for the story where the team can do a research and discuss the design in brief. As a result of the spike the team will have more clarity on the design and will have an idea of the user story that will be generated in the design process for the user story. So when they take up actual design and development of that user story they should already have an idea of the related story and will have their time allotted accordingly so that the team is not swamped in the sprint.

Answer 4

The practice that works good enough is to have (UX)Designer and Product Owner working together on designs one sprint ahead of the sprint in which those designs would be implemented.

There are some risks connected with this approach. By knowing them you can act up-front to mitigate them:

1. Design-Driven development. Designers like to create beautiful designs which might be hard to implement. To manage this risk have the Development Team review what they are working on before the Sprint Planning session.
2. Team erosion. Designer might feel he is not part of the team. To manage this risk make it clear that Development team would like to commit to 'stable' User Stories, which makes them more predictable and increases the chances that sprint will be completed. For terminology - everyone involved in the project is a part of the project team. At the same time there might be sub-team(s) that focus on one aspect of the project, ie. designs or development.
3. Pixel Perfection Trap. By accepting User Stories with high fidelity designs the Development Team might strive to have pixel perfect implementation of those. To avoid this risk make sure that developers don't focus on tiny details by sacrificing working software. Details can be implemented later, in following Sprints.