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

How to give critical feedback

You get a frantic call at 2am at night from your most valuable client, their payment processing page is returning a 404. You jump quickly out of bed and login to github to see what changed in the code. You note one of your junior developers merged his local test branch to the main branch. What do you do?

The story above may seem convoluted but many product owners have nightmares of it and even more have seen a version of it play out in real life.

But today we are not going to go technical and talk about version management, no, today we talk about the developer. Yes that is the human being who just messed up.

Faced with this situation your initial reaction maybe to simply jump at this persons neck and strangle them, 18th century style. Yet doing this would be the most ineffective way to handle the situation.

In this entry we talk about techniques of giving critical feedback.

Bad news does not age well

Don’t keep the feedback to yourself no matter how bad it is. Tell the concerned individual as soon as is reasonable.

Telling them the news early allows them to see the effect of their mistake on you, the client and the organization.

The devil vs the person

Back in primary school, our disciplinarians used to cane us while saying “It’s not you am caning, its the evil inside you”.

In our anger it becomes hard to separate the person from the behaviour. No, your developer is not the devil reincarnate she just made a mistake, thats as human as it gets.

Point out the specific behaviour and have her correct that.

Get to the point

Illusion of transparency is a phenomena in which an individual overestimates the degree to which their personal mental state is not known to others.

With this information in mind, you may realize that the developer probably has no idea why you are fuming. If you fail to give specific feedback he will overtime come to the conclusion you are neurotic, a person to hide from, not listen to.

As a power tool, you may want to have the offender rephrase the problem he caused and the steps he plans on taking to prevent such an occurrence in the future.

The folly of sandwiching

The sages of old said it “If you wish to give bad news, first start with good, then the bad and finally more good”. This is really tempting to do since we want to protect the feelings of the recipient of the bad news. Yet in practise it never works as expected!

You see we humans are particularly adept at selective hearing. The developer will hear all the words but only remember the good parts. Not ideal to inspire any changes wouldn’t you agree?

Positive reinforcement

Sandwiching maybe a bad idea but that doesn’t mean you should throw appreciation out of the window! What you need to do is actively look out for changes that you want to see and reward them as they occur.

Negative actions and behaviours have a powerful emotional impact compared to positive ones. You must always be looking to compensate for this bias. Better to err on the side of compliments.

How have you dealt with mistakes in your workplace? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Requirements | What you have been missing

While scoping requirements, sometimes we miss out on a big piece of it. We focus on what the product must do and forget about how well the product should do it.

 

In this entry, we are going to discuss some of the most common things we forget to scope.

Accuracy

We all know of the Salami fraud. Basically it’s the story of how developers in a bank managed to steal large amounts by charging only a few cents to a huge number of customers. The dudes are probably sipping Pina Colada somewhere in South America by now!

Point is, for different types of software, there are different requirements on how accurate the software should be. For a banking business, accuracy matters to the cent but for your personal blog, not so much.

Safety

More than ever software is part of our everyday life. Health happens to be part of this everyday life. You would not want your health monitoring app giving you wrong data even though it forms only a small part of your health management plan.

In this and many other such complex scenarios, software written should not add any unwarranted risk to the system.

Efficiency

High frequency trading is a form of trading carried out almost entirely by computers. The software that powers this systems are able to trade thousands of times a second to turn up profit even on very small margins.

For software engineers in Wall Street, efficiency separates those who drive to work in Ferraris and those who wash the said Ferraris.

Dependability

The software should do what it was built to do. Sometimes failure is allowed, I mean who cares that you can’t catch up on latest memes. Sometimes failure means jail time!

Usability

Software needs to be delightful to use.

Matt has a nice graphic on the same from Aaron Walters book Design for emotion

Maintainability

Software that can not be maintained is worse than worthless. What makes software so powerful is its softness. This property enables the business to get value from it even as its needs evolves. Software that can not be changed or can only be changed at great expense forces the business to stick to old ways.

Security

Privacy is a big issue for many people. Ashley Madison learnt this lesson the hard way Hackers Finally Post Stolen Ashley Madison Data.

If clandestineness confidentiality is a big part of your clients business, security is not a luxury.

How have you handled this types of requirements with your own clients? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to keep your developers motivated

What’s your most important resource?

Try asking that question to a person who owns a software development or software heavy business and wait for the answer. What you will get is mostly in the lines of:

  • Our servers
  • Our strong brand
  • Land and building

Yet they all miss a very crucial asset. I will let Steve Balmer say it.

Yes that’s right! No matter how prime your location and brand is, nothing comes close to the value provided by good developers. This is because our industry is unique in that we don’t create value by the traditional methods of reducing the costs or increasing the price, we create value by coming up with new ways of doing things.

In this way one developer can create value hundreds maybe even thousand of times what it costs you to keep them.

Yet we have lost our way and treat our developers not as gems but interchangeable cogs. Don’t believe me? Well below are some of the behaviours that kill developer morale.

Noisy work area

Coding is an intensely mental task. The open plan movement entirely ignores the need for peace and quiet to get anything done. For other professions a noisy work place is ok perhaps even welcome. For developers thou we do need a quiet space even in open plan office special space should be segregated and declared a noise free area.

Micromanaging

A developer could goof off all day on the terminal getting absolutely nothing done as you watch on! Get over the notion that you can force developers to work by watching their every step.

Instead try respecting their space and let them do what they do best. You see most developers get into the field because of their passion. More than anything else the chance to create something great is appealing. What is not appealing is a boss who thinks their Masters in Some CS course hallows them to god status.

Unrealistic deadlines

“Just quickly move this button from this page to that other page, that should take you like a minute right?” If you have ever said that to a developer kindly take a second to slap some of that nonsense out of your head.

Unrealistic deadlines are not only going to be skipped, but they bulldoze morale and motivation. They say you don’t think the work the developer is doing is challenging and worse the developer never really gets appreciated even when they have great turn around time.

No investment

The best always get better. This is a truism that you would do well to note. Because its corollary is, if the best can’t get better at your organization then they will be packing.

Ask yourself, is it really not possible to sponsor a ticket to that conference that your top developer has been hankering about?

Paper work

Everyone hates paper work. However since you get paid more, you get to do all the mindless paper pushing! Passing this responsibility down to your developers is abdication of duty.

In case you are wondering, yes, paper work does not get any more palatable when its in digital format.

Customer is the king

In the land of developers we are a free people, we say no to aristocracy. The people of this land are good and considerate we will do everything to serve the clients needs but not all their wants.

On this point, its important to note that clients are generally concerned with costs and developers are concerned with quality. Giving up quality is a very painful experience for the developer.

And while at that

The world is a complex place, there will be a million and one things to do at all times. Requests like “Fix the bug on the XYZ product and while at that create a new accounting system for the people at finance” just doesn’t float.

It is your job to prioritize the work and have the developers working on only the most important task at the time and nothing more.

How do you avoid this morale killers in your own organization? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail