How we run projects at Maido
At Maido we work in Agile Sprints for pretty much any brief that we’re working on, whether it is research led, design led, tech led or all of the above.
Sprints are an iterative, time-box approach to delivering work (from 1 to 4 weeks). Their time boxed nature focuses teams on a shared goal, giving them ownership of the work they deliver, and encouraging a transparent and collaborative work ethos.
The success of a sprint is in the discipline to the sprint events. They provide structure and focus throughout the time-boxed period. The following is an example of the sprint events in a 1 week sprint.
We encourage clients to join our sprint events, to enable regular feedback and to offer total transparency on the work that we’re doing. Clients are always welcome to join us in our Shoreditch studio for these events, or to join us remotely.
We’re big fans of remote working and we find clients also appreciate this flexibility for their involvement.
Daily stand ups are compulsory to all projects, even the small ones. They ensure transparency and enable collaboration across the sprint team.
Who: All team members when available
When: Daily - when PMs are for some reason unavailable to join, team should be self-organised and run the scrum
Duration: 15 minutes - should be in everyone's calendar. Follow up with what was decided on slack
What: Last day progress, current day plan, roadblocks and help required
User Stories Workshop & Planning Poker
A user story workshop should be held before tech development starts.
Who: Everyone on the team should participate, if this is not possible, then at the very least we make sure the following team members are attending: one designer, one developer, one project manager (and a tester).
When: Before tech sprints starts (should be part of the design handover to tech and be part of the design sprint)
Duration: Blocks of 2hrs, across 1-4 days, depending on the complexity of the project
Output: Project backlog & story points using planning poker
Throughout the project, the team can and should create new stories, this should be added to the icebox and reviewed by the Project Owner, who decides if the story stays on icebox or goes to backlog.
Sprint planning takes place on the first day of every sprint and is crucial for alignment on the sprint goals across the team.
Who: Project team
When: Day 1 (Sprint starts here)
Duration: 1 hour
What: Sprint goal definition, user stories prioritisation & refinement, functional clarification, sprint board creation
Output: Sprint goal and new sprint board
Showcase & Retrospective
This takes place at the end of the sprint. We combine two key activities: the showcase of the weeks activity and the retrospective of how the sprint went.
Who: All team
When: Last day of the sprint, the sprint ends here.
Duration: 2hrs (1hr for review and 1hr for retro)
What: Sprint demo & good, bad, needs improvement discussion
Output: Demo, sprint board closure, improvement actions