Plan Product Features with Barvas
Here at Barvas we are big believers in eating your own dog food (i’m even drafting this blog post in Barvas!). We manage all of our Product Development, Sales and Marketing Projects in Barvas. After all, if we can’t use the tool to get things done, how can we expect anyone else to?
This post will give an overview of how we understand, breakdown and plan out new product features before we go on to implement them.
There are 3 main stages to how we deliver a new product feature:
- Get clarity on what it is we need to do
- Plan out how we are going to do it
- Deliver it
This post will cover the first two points.
The importance of these first two points can’t be underestimated. They allow us to understand what the new feature needs to be and how it helps solve users problems. It also lets the Development team agree on how they will implement it and if there are any risks they need to address ahead of time. We find spending time here collaborating and reviewing plans helps keep us all on the same page. Conversely, whenever we skimp on the first 2 parts that’s when thing go wrong.
It starts with a Product Road Map.
I’ll cover how we manage and prioritize our road map in a future post, but for the sake of this article we can assume that we are ready to tackle the next item on our road map. Its been added to our road map with good reason and has been scheduled accordingly.
We usually start planning the next item once the Development team are getting close to finishing the feature they are currently working on. We try our hardest to have teams work on one thing at a time so this works well in practice. This is the point when the Product Owner and UX Designers can start to look ahead at the feature.
We use a Barvas map in the project documents area for planning each new feature.
In here we take our time to map out and review the following:
Whats the purpose of this feature and what use cases do we need to solve? This is where we get clarity on what it is we are going to do and why. Hopefully this should be fairly clear already but it’s always a good idea to take the time to ensure it still makes sense and is clear to everyone. Ideally you are strengthening an existing use case of your product or opening it up to new use cases. Be wary of just slapping features on for the sake of it. For that reason, the importance of this step can’t be underestimated.
Sometimes a feature can seem like a really great idea, but when you take the time to rationalize it and see how it fits in to your product and helps users, it might not be so great.
We use the Barvas map to document the purpose of this feature. We capture and collate any information we have on why we are doing this. This can be a mix of stuff in our heads, links to customer requests, links to road map supporting information and just general brainstorming of the problem. Once we are clear on the purpose, we map out the use cases we are going to deliver.
Some features can have a few use cases, others can have lots. It’s important not to get distracted with the nice to have things. Make sure you come away with a clear view of the ones you want to address and don’t get bogged down in being all things to everyone, as that will complicate decisions you need to make later on.
We also do some basic UI mock ups if the feature warrants it.
By this point we have clarity on what we need to deliver and we can move on to planning it out.
It can’t be underestimated how important it is to keep everyone on the same page at this early stage through good communication. Doing so makes everyone feel like they are in the loop and minimizes surprises and rework due to lack of communication. You need to make sure you are going to hit your target and it matters at this stage more than any other.
In the planning phase we tend to answer the following questions:
Are there any red flags or risks? At this point it’s a good time for the tech leads of your project to raise any technical red flags and investigate or prototype around the problem areas. De-risking the project as early as possible can help prevent the worst kind of surprises from raising their heads later down the line.
What user stories do we need to implement? Finally we start to breakdown the feature in to user stories. We like user stories as it gives developers a more easy to digest specification format. The developers like it too!
We create a branch for each user story and then we write a short description and list out any acceptance criteria. Note however that we might not put all the detail in straight away. We normally wait until the story is ready to be worked on before going into too much detail.
Any technical notes or assumptions are also added to the card.
Moving to delivery
Once we are happy with the user stories and we have agreement from stakeholders (remember to keep people in the loop!) we turn the stories in to tasks and move them to the Development Backlog ready to feed into the Development board as required.
Watch out for another post on the delivery but in a nutshell we use a Barvas task board with columns setup to reflect our workflow, for example:
Design -> Development -> Test -> Release
Summary
Barvas development is an on-going project and we treat it like so in Barvas itself. We use a single project and make use of the the project documents area to help clarify what we are going to deliver for each new feature. We then plan the feature by mapping out what it looks like in the form of user stories before turning them in to high level tasks ready for development.
Make sure you take the time to do a little up front planning to understand your problem, get agreement on what needs to be done and identify any risks and deal with them early on.
If you haven’t already, give Barvas a try a www.barvas.com
