How do you approach a new technology project using Kanban? Is it even possible to use Kanban for a new project end-to-end?
Let’s say you did the basics of setting up your Kanban process. You visualized your flow of work, set up your WIP limits and started managing that flow of work. You have been using your Kanban to work on ad-hoc work requests for a while. You’ve been pulling tasks on your Kanban board and finishing them one-by-one as they come in. But what happens when an entire new project comes in and your team has to work on it?
How do you approach a new technology project using Kanban? Is it even possible to use Kanban for a new project end-to-end?
How does planning work?
Do you need to estimate the work?
How can you predict with Kanban when the project will be done?
How is the work released to our users when using Kanban?
We will answer all these questions and provide a simplified way of how to execute a project with Kanban.
Kanban is great during the project execution or development phase of the software development lifecycle. However, Kanban on its own has gaps on handling a project from start to end. Let’s look for a quick second at the software development lifecycle to better understand these gaps and how to fix them.
Most technology projects follow the software development lifecycle. These phases are Planning, Design, Development, Testing, Deployment and Maintenance. Once the project starts and we have an idea of what we need to work on, Kanban can be easily used during these phases.
However Kanban on its own does not offer an approach on how to handle planning for a new project. Planning is where the team initiates the project and captures requirements, which is why we need to supplement Kanban with additional approaches.
You can do this using the Agile approach with the team iterating through the phases rapidly, delivering only small, incremental software changes in each cycle. Requirements and plans are evaluated continuously so changes can be made quickly. This means the Agile development approach slices the product into smaller, fully working slices.
Even though we will execute using Kanban, when working on a project or digital product, some level of upfront planning is still required even in Agile Delivery.
Agile itself has multiple ways of planning and breaking down a new project. We will cover 2 options.
Minimal Viable Product
One approach is for teams to plan the Minimal Viable Product or MVP and another approach is to plan using a specific time box.
Let's discuss the MVP approach first. MVP is a partial product that has enough features to attract early adopter customers. The purpose of the MVP is to validate the product idea early in the development lifecycle.
For example, let’s say you want to build an eCommerce website selling apparel. The MVP could be just a digital landing page in which you can market your product and potential inventory. This will allow your team to validate the interest in your product without building the entire website.
To plan the MVP in more detail, you start by breaking down the main features on a whiteboard. Features are just the high-level functionality that provides value to your end users. Examples of features for the eCommerce platform could be having product videos or ability to search for products. Each feature is then divided into several user stories as it is too hard working on large chunks directly. A user story is the smaller unit of work in an agile framework.
If you want to learn how to write a good user story you should check out our video on user stories here.
Our recommendation is your user story should be small enough to be completed within 3 to 5 business days or less. So let’s say you have broken down your MVP in all the features and user stories needed. But how do you know how long your MVP will take and when it will be complete?
In Kanban, you typically don’t estimate your user stories as long as you can keep your user stories small. Yes, you will have some exceptions here and there, but overall they should be similar in size and be completed in under 5 days. In order to estimate timing, you will need to have some historical data of the number of user stories completed within a timeframe. This is called throughput. One example is how many user stories your team completed within the last 30 days.
So if your team completed 10 user stories in the last 30 days and your MVP breakdown has 20 user stories, then it would probably take around 2 months for your MVP. To be more conservative, I recommend you add a 20% buffer for every estimate. Sometimes things take longer than expected or new user stories get discovered that need to be worked on before the MVP is complete. Keep in mind this method is designed to give you a rough estimate.
By the way, two common tools used for these types of exercises are Miro for the visual board planning and Jira for tracking the active work on your Kanban board. Also, if you want to see how to apply this approach in a hands-on way by using a real software development project, you should check out our Kanban Project Management for Software Development Teams Course.
Timebox
The other approach of planning is pretty similar to the MVP. First, we visualize the specific timebox. Let’s say 3 months split into Month 1, Month 2 and Month 3. Then have the team breakdown the features and user stories the same as before. When it comes to how many user stories to fit into each month, use the same method. Use your throughput by looking at how many user stories your team finished in prior months. Use that number for your estimate for each of the next 3 future months. Keep in mind that throughput should only count fully completed user stories.
After applying either of these two planning approaches that better fits your scenario for breaking down your project, you start documenting your detailed user story in a backlog. Most enterprise teams use Jira for this. Jira has almost 50% market share, so I highly recommend you be familiar with it. We cover how to use Jira for Kanban project management end-to-end in more detail in our Kanban course.
Once the user stories are in your Jira backlog, your development team starts pulling user stories onto their active Kanban board. Keep in mind your development team should only pull user stories based on your work in progress limits. During this Kanban execution phase, it’s important to maintain a continuous delivery flow of each user story and minimize bottlenecks.
While you execute using your active Kanban board, you can monitor your progress towards the MVP by using a roadmap, like the Jira roadmap. This will allow you to have a higher level view of the progress towards your goal. Jira Roadmap is great because it is a live roadmap. It pulls its data based on the status of your user stories from your active Kanban board.
Once a user story is complete, the Kanban approach recommends that work is deployed continuously as it is completed. This doesn’t necessarily mean each user story is released to a Production environment right away. Releases are made at each team's discretion, especially as more and more tasks are being completed. Most teams release each user story to a lower non production environment as the user stories get done. Once an entire feature is finished, the team could choose to release all the user stories associated with a specific feature at one time. Other teams deploy each user story to production after it has been tested successfully.
What questions do you have regarding this approach? Leave us a comment at info@intotheagileshop.com and we can answer them in our future posts.
Opmerkingen