In our ideal world, a Sprint kicks off with a planning meeting, midway the team might review or refine tasks and we’d finish with a Sprint review and internal retrospective. But a current project has shown us this isn’t always possible.
Almost all of our mobile app development projects begin with a discovery phase. In some cases this is enough to uncover a clear direction. In other cases, there is still a lot of collaborative work to be done to clarify exactly what the client needs and find the best solution to proceed with. Sometimes, vital unknowns can’t be resolved before you begin developing.
We’re learning a lot with this project; it is outside of our usual scope but as always, we’re working with the client to refine their ideas and discover the best solutions. When we sat down to our Sprint Planning meeting, we realised our Product Backlog felt like an unachievable list of questions the client wasn’t ready to answer.
Some of our user stories were little more than placeholders.
All the unknowns could have thrown all of our careful planning out if we tried to look too far ahead but we needed to make a start.
So, with a fresh pot of coffee brewing, we agreed it felt safer and more productive to plan what we could. We didn’t know enough to plan for 30 days of work but there were tasks we could do to progress, such as building a prototype to help the client get clarity on their own expectations and requirements. Thus, internally, it seemed logical to run this project in week to week phases.
Don’t get me wrong, we’ve got confused ourselves… What do you call a week Sprint within a 30 day Sprint? A jog?!
The honest answer? It is still a ‘real’ Sprint.
Although we’ve adapted our usual approach in terms of time, each mini-Sprint (sorry I’ve labelled it now) aka week, still starts with a planning meeting. We do this after a HangOut call with the client, during which we catch up on our progress, discuss outstanding questions (somethings are just easier said face-to-face than by email), clarify requirements and make decisions together. In some ways, this is similar to a Sprint Review which would be held at the end of each Sprint.
After the call, armed with fresh understanding, we spend time refining the top priorities in the Product Backlog, add answers to those once uncertain user stories and plan enough work to take us to the next weekly catch-up call.
This planning meeting usually takes under 15 minutes and as normal, is a chance for the team to ask questions and ensure the appropriate user stories have the necessary information included. Looking at the Product Backlog weekly also helps us to think ahead and note down any questions we need to ask in the next call so that we don’t become blocked, or start developing something out of their scope.
Although for this project we are running (no pun intended) the Sprint differently, we haven’t let our other Scrum Methodologies slip. In fact, our last Retrospective (held at the end of 30 days of effort) for this project was one of our most insightful yet. But that is best saved for another blog.
In the meantime, you can read our recent thoughts on design sprints here.
Search over 200 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!