Agile design sprint structure

After working for Skoove for quite some time, and seeing how IT companies are working on the development side of things, it became clear to me that the Agile process could also be applied to a design/concept team. The main time measurement is based with 2 weeks, and within this period you have the time to work on your tasks of course, but some other important meetings are necessary to involve the team and ensure a great end result. This relay to the second takeaway from the graph above the page, which is calendar meeting routine composed with: Kickoffs, Stand ups, Reviews/Retrospective and Groomings.

As a result, if the tasks on each sprint are well estimated and planned, the sprint should end with reviewable fully specified tickets. Depending on the acceptance criteria, the product owner, the quality insurance and a person from the development team must acknowledge each feature tickets. It should never be the role of the creator to accept his/her own ticket.

If the whole team is following the same agile sprint system and are synchronised with the same sprint starting date, then Monday is the day to gather all the tasks from, the design team itself but also from the marketing or development teams. Then the priorities are usually defined by the product owner following the main company milestones and roadmap specifications. Keeping the business expectations and other team needs on the radar is important to organise a sprint in a good way.

Following along on the diagrams you will see more on how a design workflow look like. It is not completely accurate and giving a fair representation on how things exactly happens in reality, however, it gives a good guideline and clear touch points with your collaborators.