Balancing long term vision with short term delivery priorities
I’ve been thinking recently about how our team balances the effort we put in to putting together designs for the long term vision for our service, with the work we need to do now to deliver our minimum viable product and the private beta of our service.
We want to be able to look forwards and think about where we want to go so we can communicate this to stakeholders and other services we interact with, to build engagement and to make sure we don’t back ourselves into a corner by focusing only on our immediate delivery. However, we also want to make sure we don’t start fixing problems before we verify they exist, and that we balance the effort we put into this with our delivery work.
Balancing delivery and vision
Things I wanted to take into account before adding longer term design work into the team backlog
How much do we want to do in advance?
- Having an idea of where we might go will help us understand what we don’t know yet, and what we need to validate before we go in to further detail
- However we have to be careful we don’t introduce and accept features without verifying the user need, and we want to make sure we are able and free to adapt to feedback we receive during our user testing
- We all have time constraints, and don’t want to neglect delivery priorities
How do we want to communicate the longer term design work with the whole team?
- We want to engage with the whole team and inspire better ideas by sharing our work. By having a shared understanding of the vision and what others are working on, individuals can have more autonomy in how they work towards the goal rather than working away at individual tasks.
- However, team members have previously indicated that they don’t want to expend too much effort or become distracted by getting too involved in work that isn’t immediately relevant to them
- We need to make sure when we feedback the work, we don’t get stuck on details — it will be a vision not a plan
How do we want to communicate the longer term design work to stakeholders?
- Sharing our longer term vision can help us build relationships with users, and helps them get involved and invested in the work we are doing
- We can use this to recruit users to gather useful feedback on what does and doesn’t work for them, and validate the assumptions we are using
- This needs to be balanced with an understanding that these are long term ideas, and may never be realised. We need to be careful stakeholders understand the designs are concepts, and not exactly what they will get.
How I will introduce the work to the backlog
It is important to me that we track the work that is happening in the team (see this earlier post). To facilitate the work on longer term vision, I have introduced ‘concept cards’ to our kanban board. These are very high level, looking at things that are further off in the road map, and will go straight to the design team. We have agreed on a work in progress limit of 1 card on the board at any time so that the work on these is balanced with delivery capacity. Ideas from these will inform the questions we ask and the testing we do. They will be concepts, not plans, and will be highly likely to change before they get to the delivery stage, based on greater understanding of user needs from testing.
To share the concepts with the team we are going to trial getting them up on the wall in the open, walking the team though them and then taking comments and questions on the concepts post-its to try to prevent us from discussing the details or implementation to closely, but this is a trial so we will continue to change this method based on how it goes.
I am very interested in how other teams manage this balance, if you have any suggestions or examples please let me know!