You are just from a specification meeting with your client. With you is a big list of features the client wants to see on the application. Probably its all in your notebook or note taking app. What do you do with it?
Today we shall be discussing some basic techniques on how to properly manage your backlog.
First things first
Note apps we’re simply not designed with engineers in mind. A productivity tool is needed. Trello is one such tool. Simply create a new board, put in every item to be worked on into the tool.
Some candidates for backlog include:
- User stories
- Work tasks
- Areas which you/your team needs to gain competencies in
- Major bugs (For ongoing projects)
- Tech stories (The invisible work that developers see. An example would be migration scripts)
Involve clients and developers
Once you have your initial backlog list out. Its time to invite the clients and the team to view the items. This ensures everyone is on the same page about what exactly is to be developed.
Encourage as much direct conversation between the client and the developers who will be actively writing the code.
During this stage the client has the chance to prioritize what is important since they understand their business the most. The developers however are in charge of the estimations.
However this does not mean that the parties operate in silos rather the clients should explain why certain items are priorities and the developers should explain why they have given the estimates. This is not a formalized process, casual conversation is expected and encouraged.
Select first features for development
The first features will likely correlate with the top priority features but it will not be an exact match. The first features to be developed should be developed based on criteria listed below:
- Customer priority. The most important factor to consider
- Time to market: Chose features that can enable the application to be quickly tested by end users. This enables quicker feedback cycles.
- Resource utilization: Ensure that everyone on the team has something to work on. Ie if you have a DBA there should be some DB work
- Co-dependency: Some features will depend on others, ensure to build the most depended ones first
This is not an exhaustive checklist. Communication with your client and developers should land you on the ideal initial first set.
Break down Epics
Epics are user stories that are too big to implement directly. During meeting with the client, you probably gathered a lot of them. In fact at this stage your backlog is made up almost entirely of Epics.
Now is the time to break them down to smaller stories that you can easily track.
A good rule of thumb is if a user story takes more than 2 hours to develop it’s probably an epic. Assuming developer competency of course.
Focus only on current sprint
While it may at times be tempting to develop features directly from the backlog. Focus only on items on the current sprint. The items here can not be changed by the client and are easily estimate able. Furthermore you will be computing your metrics from the items on the sprint.
Anything that is not improving is guaranteed by entropy to be getting worse. The backlog is a living list and needs to be constantly updated to align with the priorities of the users and reality as it unfolds.
How do you manage your own backlog? Tell us in the comment section below.