Update: Knowledge is Half the Battle
Reflections on our sprint from July 20th — July 31st
Every two weeks, we name our sprints. This sprint was named “Knowledge is Half the Battle” because we’re approaching a turning point in the multi-location stretch. (Unfamiliar with what we mean by multi-location? Read more here.)
At the beginning of our multi-location investigation, we created a list of hypotheses and assumptions. We’re finally reaching a point where we’ve answered a lot of those initial questions. Hence, knowledge is (the first) half of the battle. Now for the second half of the battle: we’re focused on building and testing our designs — and the product itself — to figure out if we’ve interpreted our learnings of this knowledge well, and where there’s room for further improvement.
🌹Rose (what are we celebrating?)
- For the first time ever, we (Evan, Shine and I) met up in person! We miss in person collaboration and planned an in-person meetup where we could safely distance from one another and discuss what it will take to get to our internal production launch of MOVE.
- Shine wrapped up our high-fidelity prototype!
- Analytics are embedded in MOVE, which will give us the ability to see how our users are using the software, and help us make better product and design decisions.
- Evan built out the first big chunk of multi-location: viewing summary collision statistics and traffic volume reports for an aggregated set of locations.
- A few weeks ago, Evan suggested that we should find a way to visualize our progress to better understand (1) what do we have left? and (2) how close are we to getting to our goal of being launch-ready? With that in mind, we created a burndown chart!
Here’s an example of a burndown chart. It’s a visual tool to track one’s progress over time towards a specific goal. The idea is that as time goes on (represented on the x-axis) you’re “burning down” your tasks towards your goal and the effort/time left to complete your task (represented on the y-axis) is reduced, eventually and hopefully, to zero. At which point you have completed your goal!
🌱Bud (what are we looking forward to?)
Lots of buds this week! To name a few: testing our high-fidelity prototype built in Framer; QA testing some of the first multi-location features in development; and analytics data flowing into our analytics platform.
But, by a long shot, we’re most looking forward to our concrete steps towards getting a QA environment! Over the past few weeks, we’ve had some productive meetings with our partners in technology services. We’re teed up to have a second cloud environment that we can use for QA!
This new environment will be more stable than our development environment — where Evan is frequently (1–2x weekly) deploying updates that could fix, but also break things. This QA environment will give us a more stable and reliable place to run long-term tests with our users to de-risk our launch to internal production.
📌Thorn (what can we improve?)
- Even though we have the beginnings of our burndown chart, we don’t yet have a good sense of what “done” means. As a team, we need to decide on what “done” means for dev tasks, design tasks, and other launch-related prep tasks. For example, is “done” when Evan has built the first version of something? Or when it has been tested? What happens if a whole slew of features and fixes come out of testing?
- Setting ourselves a really high bar and overestimating our capacity/time, and not taking into account COVID and pandemic-related personal and work delays.
- A few sprints ago, we were getting ready for the longitudinal study, and our direction changed to multi-location (which is a good thing, as Evan wrote about here). But the longitudinal study still feels far away.
Closing Thoughts
We still have a long way to go to reach feature parity with legacy systems CRASH and FLOW, and to launch MOVE to internal production. But we’re making progress, and there are lots of exciting things on the horizon!
