Product Backlog

In a nutshell a product backlog is a prioritized feature list that contains short descriptions of all the functionality desired in that particular feature.  While the PO is in charge of the product backlog not all of the ideas should be flowing from you.  As the PO you’ll be getting ideas from everywhere and it is your responsibility to triage, organize, and prioritize them.  Ideas may come from user feedback, making feature lists around what competitors are doing, or you’ll get feature requests from your own internal teams. 

Users may give ideas to you, but they may not be your customers.  Users may submit ideas via Zendesk tickets, web submission forms, forums like Reddit and others, internal teams/employees or social media.  These submissions may be complaints about the product or processes within it or what they wish they had.  You could build things with word clouds.  

Customers are different from users.  Say your product lies in the educational games arena.  While children are the users the customers end up being the parents buying the product.  

Metrics could also be a way to gather ideas to be added to your product backlog.  This can be any kind of quantitative data that you can get in or from your product.  

It may be important to also list any bugs or any technical work within the backlog.  Prioritizing the list will require consistent communication and interaction with relevant stakeholders so that you are bringing forth the most relevant and valuable features to your product.  

When maintaining a backlog there are many tools you can use, but for those just starting out an easy tool to use is google spreadsheets.  The first column you’d want to add is Date Added.  This will show you when something was added and allow easy sorting for that.  The next column would be Feature Idea Name.  Then after that you’d have the description, i.e. what is overview and desired functionality of this suggested feature. 

If you’re backlog contains a bug there are a few things you’ll want to include when adding it to the backlog.  One you only want one bug report in a story and be sure it has a clear title and proper grammar in the report.  You need simple and repeatable reproduction steps.  Include expected results and observed results.  Screenshots or other pictures of bug in action when user interfaces are involved.  You’ll also want to include the build/version/release where bug was found as not all customers are always on the same release.  

Prioritization criteria will vary by team and company, but it is on the product owner to come to a consensus on how this should look.  Three pretty standard criteria that can be used are impact, urgency, and engineering cost. 

Impact or importance is a way to define in a subjective manner whether or not this particular feature idea would move an important metric.  A high numerical score here using a scale of 1 - 5, with 5 being equal to high importance vs a 1, which would indicate low importance. 

Urgency would be asking the question of how important it is to get this feature out now.  1 being not urgent and 5 being very urgent.  So even though something may be impactful doesn’t necessarily translate into something being urgent.  Maybe users would be saying that something is really affecting their workflow and cutting down on their efficiency and is something that needs to get worked on right away even though this feature might not have the same impact as something else score wise.  

Engineering cost is typically where you’d want to involve someone else, i.e. an engineering manager or a high level developer you’re very close with if you don’t have the technical expertise yourself.  Scoring these stories on a scale of 1 - 5 would have 1 representing something as slow to build (1 month) with 5 being quick to build (1 day). 

Other is another column you could have in your backlog.  There are other potential prioritization criteria to consider outside of the ones already mentioned.  

You’ll want to have a total and status set of columns in your backlog as well.  Total would be a sum of any of the prioritization criteria you gave values to earlier.  Status would detail where the feature is at the moment.  It would include things like whether it needs more definition or to be reviewed even further or to be slotted into a development cycle or sprint.  The target launch date would also be listed in your status column. 

Holding periodic check-ins with relevant stakeholders to prioritize your backlog will ensure you are releasing the most valuable things for them and the company.