Fixing Bugs

Bug

Bugs, flies, mosquitoes are common in India. And some of these bugs are found even in our code!!!

Even though we try our best to prevent bugs, sometimes these bastards make their way in the cool software we produce.

So, when do we fix them?

It all comes down to one golden word. No, that word isn’t “now”. It’s Priority.

This Product Backlog is always arranged by priority – highest priority stories at the top and lowest at the bottom.

You work in Sprints while picking up new stories from the top of the Product Backlog. This would also include bugs if they are high priority ones.

So in a typical Sprint Planning, you would pick some items from the top (they could be a mix of stories and bugs), estimate them, and then go about working on them during the Sprint.

But what about the bugs that are discovered during a Sprint?

Guess what, the answer is Priority!

Let’s say you are in the middle of a Sprint with 2 days left, you have completed 3 stories and are left with 1 story. Suddenly the QA angel comes to you with 3 bugs.

But what to do? You don’t have enough time to work on the pending stories AND the bugs. So you seek PO’s/PM’s help in prioritising.

Maybe the bugs are critical. If you don’t fix them, then the stories they pertain to are useless. In this case, it might make sense to work on the bugs instead of the stories.

Maybe the bugs are not so serious and can be attended to later. Maybe you can send them to the client as “known issues”. In this case, you put them on the Product Backlog where they get prioritised for the next Sprint (or even later).

Or maybe, if time permits, you work on one of the 3 bugs raised that was critical but wouldn’t take time. That ways you can complete the remaining stories and fix the bug. But if it isn’t so, then you prioritise.

When in doubt, talk to your PO/PM for priority. They would help you decide which is more important – the bug fix or new functionality.

That Nasty Word Called Backlog

Backlog

Before Agile, I always considered the word Backlog to have a negative connotation. It always signified that I was lazy and that I had work pending. It always hinted at my inefficiency. Google’s synonyms for backlog (logjam, pileup) aren’t very promising either.

However, Agile rescued me from the dark side (ok, maybe I am exaggerating but you get the idea). In Agile, backlog is not a nasty word. It actually signifies that you have a roadmap of what shape your project is going to take in the future. A backlog is a repository, in fact, a nursery of future features where they evolve over time. It is a hopper that contains user stories that would form the product in the future.

Every feature that you would like to have in your project is present in the backlog in the form of a user story (or maybe an epic). A backlog, ideally, should be DEEP (credit for this acronym goes to Roman Pichler, author of Agile Product Management with Scrum): Detailed appropriately, Estimated, Emergent, and Prioritised. Let’s see what each of these fancy words means.

  • Detailed Appropriately: High priority backlog items (at the top of the backlog) are defined in detail and are ready to be discussed in the next iteration. Lower priority backlog items (towards the bottom) are more coarse grained. The items in the middle are, well, somewhere in the middle with respect to detail too.
  • Estimated: Each item in the backlog is detailed. Coarse grained items have coarse estimates while fine grained items have a relatively accurate estimate (if there is a term like that).
  • Emergent: The product backlog continues to evolve over time with items being added to it, removed from it, modified, split into smaller stories, and so on.
  • Prioritised: Each item in the backlog has its own priority vis-a-vis other items in the backlog. The priority of stories, like the stories themselves, can change. Overall, the items at the top of the backlog have a higher priority and the ones at the bottom have a lower priority.

In order to have a smooth Sprint (and Sprint Planning), a groomed backlog is imperative. Failure to groom the backlog can take the project on the wrong track and leave the developers confused.

If you are aware of the acronym GIGO (Garbage In, Garbage Out), you would know that wrong input can create wrong (sometimes, even worse) output. Same is true of backlog.

Do not fear having a backlog. Instead, fear having a backlog that doesn’t evolve, a backlog that doesn’t reflect the upcoming features, a backlog that doesn’t show you at a glance the higher priority vs lower priority features.

Capturing Sprint Planning Discussions

Meeting Notes A lot of discussion happens around user stories during Sprint Planning sessions. Sometimes there is a discrepancy between what gets discussed and what gets implemented during the Sprint. This is because something was discussed but not captured somewhere. We need to close this loop and make sure that that capturing happens. I am not talking about recording some fancy audio-video tool. I am referring to capturing this discussion in the user stories themselves.

As you already know, user stories are only reminders for conversations and not be-all / end-all. There are details that are left out of user stories in the favour of discussion. When that discussion happens, we need to make sure that the conclusion is captured in the user stories. It could result in updating of the acceptance criteria. Or if the discussion was around technical aspects that need to be handled in a certain manner, the developer creates technical tasks for himself under the same story.

The key point is that whatever was discussed and agreed upon gets captured. During the sprint, when you get to that story, you should be able to look at it and know for sure what needs to be done in order to be done with the story. This helps in doing a good QA and UAT as there is a firm reference to verify against.

Just Get It to Work! Really?

Get it to work

“Just get it to work”. We have said this many a times and even been at the receiving end a couple of times. We think that just getting something to work is enough. Just because something works now ensures it would continue to work even in the future. Well, life is full of surprises, some very nasty.

We have seen how things have been held together with gum and bailing wire and they seem to work at the moment. After some time, one piece begins to fall apart; you try to fix it; another part comes loose; and ergo begins the downward spiral towards certain death, at least for the object in question. Software is not very different. If you focus on just getting things to work, you invariably and inadvertently slip in a small bug. Or maybe, the code become uglier and less maintainable. So each small fix adds to the list of hidden bugs further. Some bugs do surface occasionally and get fixed in the same “just get it to work” spirit thereby reducing the quality of the overall code.

You might be aware of the above phenomena albeit in a different field altogether – managing your finance. In order to pay off some debt, you start a new debt with another lender; in order to pay him off, you approach another lender and you begin to look down the spiral. Software world recognises this problem and calls a similar scenario (as described in the paragraph above) as technical debt. You might incur some technical debt in the short run but you must consider paying it back as soon as you can. In fact, sometimes you have to prioritise it over the new features you are planning to have built.

So, while one focusses on just getting the software to work, one should also look at the mess one is creating in the process. Take some time to repay the debt. This is where good programming practices like code review, unit testing, etc. come into play. Unit testing acts like a safety net ensuring that in the haste to fix one thing, you have not broken another.

Indians are famous (or rather infamous) for making quick-and-dirty fixes. Such fixes (or hacks) are called Jugaad in local parlance. Have a look at some of them below and smile. Just make sure your software doesn’t look like this.

Jugaads

P.S: I do realise that this picture above is itself a Jugaad. My Photoshop skills aren’t good enough so I superimposed these images over a blank image.

User Story Estimations

Dilbert on Estimations

Many of us still grapple with user story estimations:

  • Should we estimate complexity (what if something is complex but doesn’t take too much time)
  • Should we estimate effort (what if something is straightforward and easy but takes a lot of time)

Going back to basics on estimations (seminal work by Mike Cohn), here are some points on how to estimate better. I have quoted Mike Cohn at some places(italicised) so that I don’t stuff it up:

1. What to Estimate

The number of story points associated with a story represents the overall size of the story. There is no set formula for defining the size of a story. Rather, a story point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on. No matter how much effort you put into an estimate, an estimate is still an estimate. No amount of additional effort will make an estimate perfect.
The story is looked as a whole and not piecemeal (iOS, PHP, QA, etc.). When we say “developing”, we are referring to end-to-end development (QA included) and delivering it to the PO / client.

2. Effort-Accuracy Curve

Effort-Accuracy Curve

Till an extent, the estimate continues to improve as you put more effort in trying to be accurate. After sometime, the “law of diminishing returns” kicks in which means that the improvement in accuracy is less as compared to the amount of effort being put in. One should stop before this point is reached.

3. Estimates are Shared

Estimates are derived collaboratively by the team, not by a single person. Even though one might be tempted to go with the estimate of who would do the job, the team’s estimate is preferred. The people most competent in solving the task should estimate it.

4. Buckets of Water and Sand

Rather than thinking of work as water being poured into the buckets, think of the work as sand. If you are estimating using 1, 2, 3, 5, and 8 and have a story that you think is just the slightest bit bigger than the other five-point stories you’ve estimated, it would be OK to put it into the five-point bucket. A story you think is a 7, however, clearly would not fit in the five-point bucket.

5. The Right Amount of Discussion

Some amount of preliminary design discussion is necessary and appropriate when estimating. However, spending too much time on design discussions sends a team too far up the accuracy/effort curve of the graph. The question is this – would that extra discussion change the estimate a lot? Can we skip that and check the finer details with the PO during the Sprint?

We can start time-boxing our discussion. We start a timer (for say 2 minutes) and discuss. At the end of the time, we draw cards. If there is a lot of variation, we again start the timer to sort out the variation and then draw again. By this time, the estimates need to start converging or the outliers can consider compromising for team’s sake unless they have a strong point for not doing so.

Making the Most of Daily Scrums

Condescending Wonka

Yeah! That’s right. Doing Daily Scrums (aka daily stand ups) alone doesn’t make you Agile. You need to be doing them well too.

But nobody told you how to do them properly. Really? REALLY? Well, in that case show this post to your ScrumMaster.

Anyways, getting on with it. Here’s how you you can improve your Daily Scrums.

1. The Purpose

The purpose of Daily Scrums is to keep the team in the loop about your progress and bring to light your impediments so that the ScrumMaster / Team can remove them.

2. Some Prerequisites

  • Update your burndown chart on the wall BEFORE the daily scrum so that the team can look at it. The burndown chart shows how many points are remaining in the Sprint at the start of each day. You can update it at the end of the day (for the daily scrum next day) or the same day when you step into the office. But it should be updated before the team commences  the Daily Scrum.
  • Update the project details with the number of Sprints completed / remaining. For example, 3/9 says that you are in Sprint 3 of the project having a total of 9 Sprints. Update this at the start of each sprint.
  • Move your story card from To-Do to Doing column (for stories that are starting) and from Doing to Done column (for stories that have been completed)

3. What to say (and what not)

Each team members mentions the following:

  • What he did yesterday (the last working day in case yesterday was an off / leave).
  • What he is going to do today
  • Anything stopping him (any impediments in his way of delivering his sprint tasks as planned)
  • Whether he is on schedule to complete the Sprint deliverables, behind schedule, or ahead of schedule. Saying this is not the norm but this is very important for us. We want to hear this.

There’s a good chance that when a team member mentions something as part of his update, you might have something to add to it / respond to it. If it is a one-liner comment / answer, go ahead with it. If it becomes a back-and-forth discussion, then stop there and take it offline. Do not continue to discuss it during the Daily Scrum.

4. How long does it take

A Daily Scrum should not take more than 15 minutes. In fact, if you are doing Step 3 above well, 15 minutes would be more than sufficient for the whole team.

5. Pay attention to what the team says

Sometimes we do not pay attention to what the a fellow team member is saying because we are not working on the same story. This is not right. You are still a part of the same team. The whole point of having a team is to let the team members help each other out. Isn’t that how a team is defined as? Even if your fellow team member is working on a different task than you and he is facing some issue you can help with, volunteer to help him out. Your help would not be forgotten and when you get stuck in the future, your team members would help you out too.

Also, in case, a team member falls ill or has some emergency which causes him to be away from his project, you might be called in to help move that story along. If you pay attention during each Daily Scrum, you would not have much trouble when you are filling in for him.

So pay attention to who is saying what rather than having side conversations (which disturb others trying to listen to the speaker) or staying tuned out.

What the heck is an MVP and Why you should build it

MVP

As an entrepreneur, you are probably aware of the buzzword called MVP. Maybe you understand it to some extent. But do you REALLY understand it well enough to build it? Let’s see if I can help you garner that understanding.

MVP, as you might already know, stands for Minimum Viable Product. Now, you might have this belief that you must take all the features you have thought of to the market at once. You want to make a big impact and for the same you want each one of those features in there. I am inclined to agree with you but I have learnt that it doesn’t work like that.

Let’s say you have a set of features that are at the core of your product. This core defines your product. This is how you set yourself apart from the competition. Or this core helps you create a new market altogether. The MVP revolves around this core. It encompasses those features that you absolutely must take to market lest your product would be non-functional.

It is with this MVP that you make your first launch. Relax. I am not talking about launching a half baked, incomplete product. I am talking about having just enough features that makes your product identifiable. At this moment, you are looking for feedback from the market. You are looking at early adopters to test your product and provide you insights into what they like, what they don’t, and more importantly, what they want in addition to the MVP. This last bit helps you identify those features that would make it to your next release. Maybe you had a different feature set in mind but is that something the market is seeking. Would those features help you gather more customers? Maybe or maybe not. But the key to answering that question is your MVP.

Structure your product features in a way that you can build your product iteratively (adding more layers to existing features) and incrementally (adding new features altogether). All along the way, you keep testing the market and have your ear to the ground trying to listen to what the people are needing. You let them PULL features into your product and not PUSH fears onto them. This is the essence of Lean from which the concept of MVP stems.

Always look at your product with a beady eye and scalpel in hand ready to cut out the fat and trim it to what you can do with. Let the market test it out and let you know where it is thinner than it should be and where it can be cut further. In order to streamline your product development while achieving the maximum, you need to focus on the minimum.