Agile Web Operations

Photo by jpctalbot

The final building block of our introduction to agile is velocity. In addition to employing user stories to break down big features into manageable junks, maintaining a backlog for ruthless prioritizing, and story point estimates, velocity will help you find out what you can deliver in a week.

Photo by HeavyWeightGeek

Estimation of Development Time is Hard

After discussing which issues we tried to solve by introducing agile practices to manage a remote development team, using User Stories to be able to compare requirements and building a Backlog for ruthless prioritizing I want to share our learnings about agile estimation of User Stories.

As you might have experienced, estimating the time required to build a certain piece of functionality is not easy. Either you have no clue and guess "3 days" or you have a feeling it will take around "4 hours". Now what if that 4 hour story takes you 12 hrs or more? Maybe you know you're too optimistic so you conservatively estimate 8 hrs. But it still ends up taking you 12 hrs. In fact, the longer you've been a developer the more you'll come to realize that your time estimate is hardly ever right!

Photo by mikefats

So far, I've talked about how I went for Introducing agile practices to manage a remote development team as well as User Stories - Making Sure Your Customers Get The First-class Seats. While User Stories are a good start, enforcing ruthless prioritization of these stories can really streamline your development processes.

Priorities get mixed up when you're doing to many things in parallel

One of the worst things about dealing with too many issues at once is that every one of them seems to be the most important one when you're looking at it by itself. The reason for such misjudgment is that while you discuss one issue via chat, phone or email, you often don't see the whole picture. Before you know it, you're constantly changing priorities and generating a lot of context switching in development.

Starting more work does not lead to faster results - on the contrary!

If you keep talking constantly about all your issues, you tend to think that everything is being worked on in parallel even if you have only one developer. So your expectations rise to unrealistic levels and you tend to push harder (often to the misfortune of both product quality and your team's morale).

Photo by Clinton Steeds

In my last post about Introducing Agile Practices to Manage a Remote Development Team I described the issues we faced with our existing development process and provided a step-by-step overview of the agile practices we implemented. In this post, I want to introduce you to the concept of User Stories and how you can use them to streamline your development process and put your users first.

Concentrating on Individual User Values Instead of Complete Feature Sets

One of my main concerns was the mix of topics being simultaneously discussed: Complete new modules and single features as well as typos and minor layout enhancements. To simplify discussions, I asked everyone to break down bigger features into individual user functionalities - User Stories. Instead of trying to fully specify a complete module like Questions & Answers, we started to talk about things like
"As a user I want to be able to ask questions so that I can solve my issues with my car" or "As an expert I want to be notified about new questions regarding my field of expertise so that I'll be able to help quickly".

What would you say if I told you that you can double multiply the output of your development team while simultaneously increasing quality? Let me show you how I made this happen in a small team a couple of months ago.