Tips on managing your backlog

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:

  1. User stories
  2. Work tasks
  3. Areas which you/your team needs to gain competencies in
  4. Major bugs (For ongoing projects)
  5. 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:

  1. Customer priority. The most important factor to consider
  2. Time to market: Chose features that can enable the application to be quickly tested by end users. This enables quicker feedback cycles.
  3. 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
  4. 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.

Backlog grooming

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum in 4 easy steps

A lot of methodologies can not make claims of making your team work 400% faster. Scrum however is not one of those.

In the 22 years of it’s existence this way of working has proven particularly effective in almost all human endeavour in which teams we’re involved. Yet it’s effectiveness is matched only by its simplicity. If you have not been using Scrum in your projects then now is the time to start.

In this piece, we will look into what the process entails so you can give it a spin in your own team. You will note that, we assume what you are working on is a software project thou the principle can be easily replicated in other disciplines.

The people

At its heart, Scrum is all about the people. Roles defined by the methodology are not meant to enforce rank but provide value, as such all team members in a Scrum team are considered equals.

Product owner

Power without direction is useless. The product owner is in charge of the vision of the team, in short he/she is to ensure that the effectiveness granted by Scrum is not wasted on busy work but rather contributes to the business value of the project.

The PO can then act in lieu of the client on the day to day activities of the team.

Scrum master

This individual should be well versed with the dynamics of the team and fundamentals of Scrum. He/she will lead meetings, track progress and ensure that the rest of the team is living up to the ideals of Scrum.

When problems arise, as they will. The Scrum master is in charge of taking care of them ensuring the team is not affected by the minutiae of office politics.

Team

This is the technical muscle. Ideally should consist of 3-4 individuals. In my experience the combination of;

  • 1 designer
  • 1 front end developer
  • 2 back end developers

does the magic.

The assets

The materials needed to start out are readily available and can be found in any store with office supplies.

  • Board or glossy wall
  • Office stickers
  • Tape
  • White board markers

The process

The backlog

Each and every single thing that can be done by the team is written on a sticker. This are actionable items, i.e stories that can be converted to software.

Items such as “User management” don’t count, they should be broken down to something like “User dashboard showing all users and current login status”

A relative estimate should be attached to the item. So that you can have values like:

  • Easy
  • Intermediate
  • Difficult

Fibonacci numbers also work. So something like 1,2,3,5 … for growing complexity. The numbers are all relative to each other ie we can say the item with the estimation of 5 is estimated to take five times longer than the one with estimation of 1 and two times longer than the one with 2 etc

This works because while humans are terrible at absolute estimates, we shine on relative ones.

The sprint

We all love the feeling of getting something done. That’s exactly what the sprint is targeted at.

The team selects items of highest priority to get done within a certain period. This period is ideally two to three weeks. The items of highest priority are then moved to this list.

During the sprint all items on the sprint list must get done. In this case getting done means having the entire feature/story fully completed and working. In fact at the end of the sprint the team must demo their work to other stakeholders in the project including the client and representative of the end user.

Critical at this stage is that the items on the sprint don’t get added. That is no new feature can be requested. If it is, then its added to the nacklog.

Daily stand up

The daily stand up is a meeting like no other. The stand up in the name is literal, the meeting should be held with everyone standing up. This should discourage any would be “hearty speakers”.

The meeting itself should last at most 15 minutes with each member covering the following essential areas:

  1. What did you do yesterday to move the sprint forward?
  2. What will you do today?
  3. What are the obstacles in your way?

This ensures everyone is has full information on progress of the project. The Scrum master leads this session and should take care of any external or internal obstacles to project progress.

End sprint

At the end of the sprint the team should have a demo ready for the client showing what has been done thus far in the project.

Once the demo is complete a review of how the sprint went should be done with the purpose of identifying inefficiencies in the process. The team can then strategise on how this challenges can be addressed on the next sprint.

The identified improvements should take priority in the next sprint.

Conclusion

So there you have it, Scrum in a nutshell, kind of simple isn’t it? Taking the principles outlined above into practice will be the biggest challenge that your team will face.

Will you take on the challenge? Talk to us on the comment section below.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail