5 Things to Consider When Creating Your Backlog • Slash

A backlog is the backbone of a project. It allows the project lead/product owner to understand and break down the project into digestible chunks for both their understanding and the team’s. It is a project management tool that helps everyone involved and keeps the project on track. It’s also a fantastic way to track progress as you’re able to understand down to a minute level what has and hasn’t been done. Certain things need to be taken into consideration when creating your backlog. Herein we’d like to introduce five points we believe to be integral to any project’s backlog.

Table of Contents

Business Value

Our first point is business value, since in the end, this will drive most of the business decisions. Most clients, due to their experience, role & mindset, only see progress through business value. Business value is what brings value from a business perspective to them and the product. The client’s focus will be on this, as if they are seeing it through a singular lens. The product owner defends the product, but the client defends the business, so therein lies the need to explain and create a backlog around this.

There are many ways to add value; however, within your backlog there will be certain stories that provide more value than others. The key is to find the right balance as to which stories are prioritised and which are taken care of later. For example, technical stories typically provide little business value as they are invisible to the client. Remember that what matters to the client is not always what matters to everyone else involved in the project. So understanding in advance which features, epics, stories and so on provide the most business value to your client will simplify the organising and efficient planning of the backlog.

Pre-Estimation

Knowing what is what and how long things will take requires technical know-how and experience. Pre-estimation is a very useful tool and thankfully product owners are acutely aware of how complex certain things are compared to others. In order to adequately understand the complexity and time needed for certain tasks is key for forecasting a project’s timeline; hence, the backlog must be completed to do this pre-estimation.

Of course, it’s possible to have the team estimate every individual task with story points, though naturally this would not be the most ideal approach. Why not? For one, story points innately shift over time as the team grows and works together on the project. Therefore, the big picture needs to be understood initially via the backlog.

Now you could opt to engage one or more senior/lead developers to help with quick estimations at an epic or story level. This will allow you to create sprints & project timelines in advance more accurately and reduce any risk associated with the unknown; however, it’s not the perfect solution since their time is a precious commodity & tends to be coveted by many people & projects. Yet fear not, in a world of agile teams where estimating & planning are both active tasks, it can bring a better sense of the road ahead both reducing the risk and margin needed.

Pre-estimation is important, but it’s equally important for the client to understand that no estimation is perfect and all are subject to change. You simply do your very best to get as close to the target as possible and in general your estimations will help the project run smoother, giving clients some understanding of what to expect as timeline & budget concerns are always on their minds. It may only be an estimate, but understand the client will greatly appreciate it as it’s vital to their own business plans.

Prioritisation

Everyone’s priorities are different, but how does a PO set backlog priorities? Being able to understand what goes first and what comes second is the ultimate balancing skill. The product owner must make this decision, typically in agreement with the client, though in essence it is the product owner’s responsibility to push for a certain progression in the development. Thankfully they are in a unique position, privy to multiple sources of information that aid in creating this priority. There are three key points herein we’d like to touch on…

Business Needs

It’s important to consider the business needs of the client when prioritising. For example, does the client have an upcoming demo and what is their expectation therein? Do they need a specific feature to convince a potential partner or investor? Therefore, understanding your client’s plans can help guide your prioritisation of the backlog to fit their business needs.

Technical Requirements

In addition to business needs, there are naturally always technical requirements that must be considered. Is there a specific technology that needs to be integrated/developed which is foundational for more critical things ahead? Anything technical necessary to ensure that demo goes smoothly? There are certain technical complexities that require you to spend time setting them up correctly before you can start delivering features that will generate business value to your client.

Timeline Requirements

Finally, the timeline is another point that can drive backlog prioritisation. There are often deadlines for MVPs, minimum viable products, which are used to drive & shape the backlog to fit these timelines. What needs to be delivered & by when? There are deadlines related to contractual agreements, launch schedules, business requirements and more. Knowing all these will help to fine tune the prioritisation of the backlog.

Consistency

When creating a backlog, consistency is essential as it will create a structure for you and everyone who follows. Everyone likes order and patterns, this is why we spend so much time organising things to how we want them in our lives. A consistent backlog assists in clarity for everyone involved by creating a patterned output that translates to familiarity.

Consistency can be found in multiple aspects of the backlog; the idea is repetition. Essentially the goal is to help people understand how & where to find specific information and what said information represents. For example: the writing of acceptance criteria, the breakdown of epics into multiple stories, the separation of technical vs user stories, the distinction between BE and FE stories and more. Consistency within your backlog will help maintain the clear structure that you have created for the backlog, one that is easily understandable and digestible for everyone involved.

Coherence

Our final point touches on the need to create a backlog that makes sense as a whole. You can plan for individual parts, down to a granular level, but it still needs to make sense as a cohesive whole from a product perspective. Consider that while a sprint can deliver multiple features, it’s worth trying to finish the flows end-to-end as much as possible. For example, you don’t want to do the login screen followed by the registration screen at a much later date, or leave the password reset for another time. There are many reasons not to do this, but in short it just makes sense to create those end-to-end.

Let’s go one layer deeper to understand why this is. Simply put, our brains work best when trying to understand a specific feature from beginning to end. We like to see how the feature starts, works and finishes without having to imagine any of the steps along the way. Certain parts of a feature can appear fine on their own, yet when put in a flow, often show inconsistencies or issues. If you show the client a password reset screen and they have no idea what registration looks like, naturally problems will arise.

Therefore, making connections between different parts of a feature can be challenging for developers and clients to fully grasp without actually developing them, and facing the issues they require. The key here is following a more logical process in how to deliver features because testing works best when the entire feature can be tested rather than the individual parts. Keep in mind that client feedback tends to be more constructive when looking at a whole feature. They typically do not have experience, and you cannot expect them to, in making mental leaps with their imagination to decipher how a feature will look and work without actually seeing & using it for themselves; especially if this is their first product development experience.

In summary, a well-planned backlog that considers the points laid out above can aid in a smooth development experience for the client and developers. It’s important to understand both your client and development team so you can play to their strengths to deliver the best possible experience and ultimately, the product they need developed!