Skip to main content
deleted 48 characters in body
Source Link
Andrew Clear
  • 2.4k
  • 15
  • 20

Thanks for this question.

From my experience theThe 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.

Thanks for this question.

From my experience 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.

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.
Source Link
Bartek Kobyłecki
  • 1.7k
  • 1
  • 12
  • 21

Thanks for this question.

From my experience 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.