Building Big — Preparing a Backlog
Part 1 in a series on Building big 1, 2
Here be Sharks!
Yes I know the flag means it’s safe to go surfing but you get my sentiment.
Preparing to Build.
When building or attempting to build something ‘big’ we should actually invest ourselves in preparations for the task. There are a few recommended methods but I will be basing this series on agile/scrum/kanban methodology and they have recommended pathways already.
How to prepare a project backlog?
This means
1 . Think about priorities and what you would like to accomplish with this project. Err on thinking about thinking in more detail rather than in less.
2. Writing user stories here we will concentrate on writing in as much detail what we want the end product should be for the end user. e.g I as a bank account holder want to login so I can check my balance. Here we have broken down this aim to a who, what and a why if we use this as a title for user story it becomes easier to list down what need to be done for this to be achieved.
3. Make rough estimations of how much time and effort items on your backlog will take to finish.4. Splitting work, this is an important step work moves along much faster if we all know who is responsible for it.
5. At this stage it would be wise to think about Quality Assesment and hoa we are going to measure the quality achieved and at which point will be ok with releasing.
6. How we are going to deploy/publish/launch, version control and other such factors should also be determined and noted.
The Product Backlog, in its simplest form, is a list of things that people want to be done to the product, in priority order. Anyone can add anything to the Product Backlog.
Anyone.
Anything can be on the product backlog bugs, features, risks , the whole product.
Only the product owner can set the priority of the items.
Items in the backlog should be expressed in business terms, ideally items here should represent value to the end user/consumer of the product.
Functional requirements for the product should be expressed as features although we should note that none functional requirements can be added too e.g make app faster, shoot higher definition, write with more depth. Take care to write achievement tests or factors for this. e,g Shoot higher definition to enable us to export 8K videos
Prioritize items in this list by means of positions on the list. The items that need to be done sooner can come up higher on the list. Things at the bottom of the list are likely fuzzy or not very well defined (good to haves).
Why prepare a backlog ?
The above steps can result in some powerful results I’m speaking about level over 9000!!!! so be prepared …
- With this approach prioritization of the work now becomes norm and a business function. There is a choice between adding cost and doing more and this can easily be decided by a conversation.
- Risks or issues that are bothering teams can be put on the backlog and everyone can settle down and know that once its on the log it will be gotten to and resolved. This helps with not losing context in day to day work and helps with limiting *WIP.
Appendix:
- product owner — Individual or system tasked with prioritizing work for this specific product.
- WIP — Work In Progress, this is are the items being actioned by members of the team or yourself currently. Try to limit this to as little as possible multitasking has been shown to reduce efficacy.
- Items towards the top of the backlog should ideally have a huge amount of detail, They should be defined without dependencies i.e can be delivered by themselves. Err towards breaking down work into smaller parts.
Remember that a clear definition of the backlog just needs to be one step ahead of what is being worked on.
At this point if you carefully constructed your backlog if for nothing else you will have a queue of work in place, and this is amazing in itself.
Next time we delve deeper into initiating the project.
References:
