All development starts from ideas. It’s crucial to capture those thoughts properly and drive them systematically towards development. I have helped more than a hundred companies from small startups to large multinational corporations to get their development operations up and running. In this series of blog posts I share some basic principles that any startup founder should know about agile software development management.
The most common way to get your ideas wrapped for an agile development team is to create a Product Backlog
. In the most basic form it’s a prioritized list of deliverable items: Ideas, features and future plans such as user stories, requirements, wireframes or technical specifications. Product Backlog is the most important forum between your business development, customer collaboration and product development.
Each item on Product Backlog represents one small feature or improvement that can be implemented by developers typically within less than a couple of days. If an item takes longer to develop, it’s recommended to split it into couple of smaller items. We don’t want to get developers stuck into massive task a week after week. Work productivity is easier to manage when plans are split into smaller chunks.
Because each item is an atomic piece of information, Product Backlog can grow significantly on a long run. There’s always new ideas growing as soon as earlier ideas get implemented. Product Backlog is not a project roadmap, but a continuous set if constantly growing ideas. For that you need to get a proper workflow and related information well organized.
Kanbans such as Trello or sheets on Google drive grow easily too large for this. Fortunately there are a lot of great tools to manage a proper Product Backlog. These tools are called issue trackers. The most common issue trackers include for example YouTrack
. If your development team uses GitHub
, they also provide simple tools for Product Backlog management.
Issue tracker is often a bit falsely implemented as an extension of a help desk platform or just developers’ tool for bug tracking. It can be applied to both of those use cases, but in fact with a properly managed Product Backlog it becomes your most important interface between business planning and product development. That’s why you should keep the issue tracker right next to your business planning tools and easily approachable for both technical and non-technical people. This requires some configuration.
Each item on Product Backlog should get the minimum set of details:
Summary explains the feature in few words and helps to identify an idea
Description provides full details what needs to be developed. It’s often in a form of User Story.
Discussions must be visible directly under description. This includes questions, clarifications and decisions.
State provides a workflow, typically for example “New Idea", “Scoping" and “Ready for development"
Priority tells how urgent the feature is: “High", “Normal" or “Low"
Complexity of the work, typically in form of Story Points, for example 1 = simple, 5 = normal and 10 = very complex
Now that you have a collaborative Product Backlog established, it’s time to start adding ideas. Invite your whole startup team from co-founders to developers to ideate and provide comments as much as possible. Product Backlog should be the main discussion forum of your team. This way everyone gets familiar about product development visions in the level of details that helps the team to understand the full complexity of the topic from business and technical point of the view.
Product Backlog captures the decisions and background information into a seamless flow of information around ideas. All discussions should relate directly to your business goals. But don’t be too strict: Freeform ideation around Product Backlog is just like any other brainstorming - you shouldn't kill an idea even if you don't want it to get developed for now. Any idea might become useful later. Just keep them in the state "New Idea" until an idea becomes more important or clearly obsolete.
After you have added enough new ideas to your Product Backlog, you can start thinking which features need to be developed first. Push those items into “Scoping" state and ask your developers to give an estimate about Complexity. Typically this happens with Story Points that explain relatively how complex the feature might be: How many components are needed, how many integrations are connected or how many decisions need to be made before this feature is fully implemented.
The concept of Story Point is fairly easy: A simple task that can be implemented within less than half-a-day can be for example one story point, and an item with a lot of complexity and uncertainty can have ten story points. Each team has their own way to make these estimates - ask your developers how this is best organized for your purposes. And remember that complexity is different topic than a time estimation
, which becomes important later in the development process.
As soon as you and your development team can agree about complexity of the work, an item can be pushed to “Ready for development" state. Now all related specifications should be available for developers and the item is simply waiting for development to get started. There can be a lot of items like this. It might be that your developers are busy with more urgent items for a while, but always make sure that there are “ready for development" items available at least few weeks ahead. Amount of Story Points can expose this: If you have only twenty Story Points waiting for development, you need to focus on scoping to provide more.
Keep your Product Backlog well organized. Items that are still just ideas without a need for scoping should be at the end of the list. Items that you are currently scoping with your team goes into middle and those items that are ready for development should be kept on top of the list. Priority field of an item tells how critically the item should be pushed through this workflow. With well organized Product Backlog your developers can easily see which features should be implemented next and what is the current focus in development overall.
Leading a development team or SaaS startup?
Would you like to boost your team's productivity with
process improvements, new tools or agile management? You can
hire me online for interim management and coaching.
I provide remote consulting to companies mainly
from US East Coast, UK, Central Europe and Nordics
having outsourced teams across the world.