Now that we know how to measure out velocity, we can use that metric to figure out one of two fundamental things:

1. How long will it take us to get there?
2. How far will we get?

Velocity can’t answer both questions for us, but if we’re willing to concede and control one of the two variables, either the distance or the time, then we can project what the other thing will be.

For example, if the team is getting pressure to release by a certain date (sound familiar?), then with your velocity you can project how many features you’ll actually have done by that time frame. If, however, the team is under pressure to get Awesome Feature X done and released, then you can use the same formula to project when that feature will be done.

With road trips my family almost always chooses to control the distance and project the time. My wife wants to go to Disney World, for example. That’s choosing the distance factor. Now if I know my velocity I can project how long it will take us to get there. On the other hand, some times we want to do a quick weekend trip to somewhere just to get out for a few days. In those cases, we’re bound more by time, because we don’t want to be on the road the whole weekend. In that case, we constrain our time window, and see how far that will take us.

This is where the real power of knowing velocity comes from. Your implementation team is the engine of you car. Understanding velocity and how it works and what it means to your team is like having a speedometer. Until you know about velocity, you’re like driving a car with a broken speedometer.

A lot of common questions of project management start being fundamentally changed when you introduce velocity. For example, a question like, “How do I make my team work faster?” changes to something like “How do I increase my team’s velocity?” I’ve seen this happen almost any time that a team embraces these concepts, and it’s not only a change in the wording of the question that is profound, but in the meaning of what is behind it. Velocity is a historical metric for your team’s progress, so asking a question like how to make that number go higher because a much more scientific question completely. The answer is can be varied, but it all comes back to where it started, with the velocity. Try something out on your team, then wait and see how your velocity changes. You’re doing an experiment now. Not only that, but you know how to measure the results.

Enjoy your new found technique. If you have any questions or comments feel free to contact me.

Measuring your team’s velocity is actually an easy thing to do. Your team will start working in release cycles that are broken down into parts. The lead or the project manager is usually a good role for determining how long these cycles should be. Some teams will have a release cycle of 3 weeks. Others will have longer cycles, it’s completely flexible. The key is to stay consistent. Once you make a choice on your cycle, you need to stick to it. The reason will become clear later.

The other thing to note here is that you can break down your release cycles into parts. My team calls them Iterations. I have some teams that work on 1 week iterations. I have other teams that work 3 week iterations. One team I lead has a 2 week iteration. The release cycles for all these teams are different, too. Some teams release at the end of every iteration. Other teams release every 2 iterations. I’ve worked on teams where the planning of the release was done more rigidly because of customers, and we would release every quarter or maybe 6 months. The point with those teams was not so much about the release cycle, but that the iteration cycle was still small. The largest iteration cycle I’ve worked on was 4 weeks long I think.

The point of the cycle here is to do one thing: allow your team a consistent amount of time to work on an attainable goal. That attainable goal is a certain number of features. How many features you ask? It completely depends on your team’s velocity! But when you first start, you don’t have a velocity, so you have to do a couple cycles just to figure out what the team can do.

So say you have 30 features to work on. You decide to have your team work in 3 week cycles. At the end of their first cycle, they complete 3 features. One of the features was valued at 5 points (from the estimation sessions, remember), and the other 2 were valued at 3 points. That means the first cycle your team finished with a velocity of 11. That’s all there is to it! Now you repeat the same process over again. Do another cycle. Maybe the team got 15 points completed. Now average the two cycles together. The team’s velocity becomes 13. Rinse. Repeat. That’s how velocity is measured.

This is why your cycles have to be consistent, because you’re taking an average of the points your team completes. If you change the cycle length, then it messes up your velocity values. Now, having said that, there are points where it’s appropriate to change the cycle. I’ve done it many times before, but you have to account the change in your velocity calculations when you do it.

Now that we know how to measure velocity, we can use it to figure out things, which is our next topic:

Projections

When your team goes through estimation, each feature needs to be assigned some “credit” so that you can then use that amount for projection and release management. The issue is what you use as your “credit”. A common idea would be to use “work time” as the credit. There are a couple problems with work time, though. First, each team member’s work time is different, because their productivity levels are different. This means that when they estimate they would have to think about how much time it would take for them to complete the feature, which is always going to be different with the other members, so they won’t be able to come to a consensus. They have to come to a consensus when estimating each feature, so work time won’t work.

Since we know we can’t use a metric that varies on each team member, we need to pick something that is relative and allows the team to vote as a whole. That’s why my teams use a concept of “points”. We use a modified version of the Fibonacci sequence (i.e. 0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, infinity). We don’t go past 34 usually because after that the risk that the estimation is significantly wrong is too high. That brings us to another point worth mentioning.

When you are estimating how long it takes to do something, it’s better to try to keep your features small. The same is true for road trip planning. If I am planning a trip just outside of Atlanta (where I live), then it’s a lot easier for me to figure out how long it’ll take me to get there. If I’m just going up the road, then I might even be able to get my travel time figured out down to five minutes. The farther away I go, the harder it is to accurately estimate. With a trip as far  as Orlando, I know I’m only accurate within an hour or two. That’s a much larger margin of error than five minutes!

The same is true in estimation and your credits. If you assign a feature a large amount of credits, then the margin of error is much larger for that feature. That’s also the reason why we don’t just let the team pick any number they want. If a team member is having trouble between an 8 and a 13, they have to pick one or the other, they can’t say “I really want to choose 10″. The point here is that there’s a margin of error because of the uncertainty, and the Fibonacci sequence shows that uncertainty in the estimations very well.

Once you’ve identified your credit system, then you can use that system to determine your team’s velocity. And that brings us to our next topic:

Determining your team’s velocity

Let’s start by identifying the major players here. We have users, clients, managers, leads, analysts, and the implementation team.

Let’s start with the easy ones. The users and clients really wouldn’t have any idea of how much effort it would take. Sure, they have an idea of the benefit, which relates to the ROI, but not the effort. That leaves us with the rest of the actual team.

Who among the rest of the team would know how long it takes to build something? The people doing the building. Who does that not include? Managers, analysts, and maybe leads depending on their role. The implementation team knows how long it takes to build things, because they’re the ones building it in the first place. They may not know, however, what it is that their building. That’s where the analysts, leads, and most importantly, users and clients, come in. They are there to help the implementation team understand the features so they can give a good estimate on the effort involved.

One thing of note here that might not be so obvious is how does the estimation get done? Let’s say you have 3 people on your implementation team. Do you assign Feature A to team member X and ask X how long it’s going to take to do A? No. The reason you don’t do this is simple. Why is surveying so popular? Because statistically speaking, if you perform a survey correctly, you can be relatively confident in the results of the survey. Or in other words, the more people that are willing to say “Feature A is going to take X long”, the more confident you can be that those people are correct. If I asked my entire team of 10 members, and you asked only 1 member of your team, which estimate do you think we would be more confident in? That’s not to say that it would be right, but it’s more likely to be right.

Is it as simple as getting everyone together and going over the features and just saying how long it’s going to take? Well, not exactly.

We also need to talk about our credit system.

Let’s say hypothetically that you’re leading a team. How would you want to measure this metric?

Do you want to gauge this metric from your users? Maybe they could tell you in terms of features how fast your team is. An example of that might be, “It took Widget Company 6 months to produce a new release with 3 major features, and 2 minor features.” There’s a problem here, though. How do you know how much effort it took to accomplish these features? Users may call a feature major or minor, but that certainly has no correlation to the effort involved to produce that feature. So that won’t work.

Does the project manager know what the metric is? To answer that question I would ask: Does the project manager have any more information about the effort involved for each feature than the users from the previous example? If the answer is no, then you’re in the same situation.

Leads have the same problem. Even technical leads, who actually know exactly what’s going on with their teams at all times, and probably even do a fair bit of the coding themselves, can’t figure out the effort by themselves. They’re missing the information just like everyone else.

And this is where we’re left. We need to know what the effort is. How can we figure out the effort? Well, what if we estimated the effort involved for each feature, and then tracked the progress of the team for each feature. After they completed that feature, we could give them “credit” for that effort. Then we could use this “credit” as a way of describing how fast our team works.

The trick to understanding this “credit system” is in our next topic:

Estimation

Or, more simply put in mathematical terms:

distance = rate * time

Projects work the same way. The only difference is that people call these things different names. For example, the “rate” of your project is how fast your team works.  For my teams, we call that velocity, which we’ll get into more later. Distance is where you’ll be when your done.  You could look at that in a lot of different ways. For a lot of projects, that is simply “how many features have been completed?” And time is, well, time.  It’s how long your team works on your project.

If you know two of these variables, then you can calculate the third. For google maps, this was a simple matter of acquiring the right data for the job.  Mainly, getting the distance of the road segments and the speed limits associated with them. Nowadays I think they even take into account for traffic to some degree, but that’s not within this scope. For projects, though, how can we figure out any of these? Can we figure out any of them? Well, let’s first start off by stating something that should be obvious at this point. You can’t get calculate two of the terms with only one piece of information. What do I mean by that? If you tell me how fast your going, that doesn’t mean you can ask me how much time and where you’ll be.  It just doesn’t make sense.

The same thing applies to projects. All too often I see project manager’s doing something to the effect of “We need features X done by such and such a date”. That’s the same thing as you asking me to solve the 3 variable problem and only giving me one variable of information. You just can’t do it. It doesn’t make sense. What happens in the real world with these projects is that they don’t deliver what was promised, or they have to push back the date. Very rarely do they under-promise and over-deliver.  That almost never happens. Looking at it in this high level clearly shows why this is so flawed. The project lead needs to know more information. If the lead knows the rate, and they know the time, then they can figure out the features (distance). Or they might know the rate, and they know the features to release next, then they can calculate how much time it will take.

It’s simple. Figure out two of the variables, and you can calculate the third. The interesting thing is what the project manager usually has control over. The manager can usually manipulate the feature set that needs to be delivered, or the date, but not both. Either way, you get one of the variables. The other one you need is the rate, or what teams refer to as:

velocity

Planning a trip and planning a project are almost exactly the same process.  My wife wanted to go to Orlando, so what was the first thing I wanted to know? How long is it going to take to get there.  The same thing is true with projects.  Only, the question you might have may not be “how long”, it could be “how much will you get done in X amount of time?”, but as I’ll explain soon, they’re actually the same question.

Right now my way of planning trips is to just jump on google maps and plot a course between my house and my destination, in this case a rental house in Orlando. In a ridiculously short amount of time google maps will give you not only one route, but multiple possible routes, all of which have total distance and driving time shown for you, and google maps will even pick the one it likes the best for you.  It’s pretty awesome stuff, but it’s not ideal.  Why isn’t it ideal? Well, I should say it actually is ideal.  In fact, it is the ideal timeframe.  When the day comes to head out on your trip, what happens when you hit traffic? Or if the road is closed because of construction? These things slow you down, off of your ideal path. That’s not to say that it’s a waste to plan your map with google maps,  but once you’re on the road you’d be much better off if you could get updated with more info while you travel.  Instant knowledge of how your doing on the road.  Oh, if only there was some device that could do this for us. Flash forward to.. well.. now and go get yourself a GPS.  This guy tells you not only how to get where you’re going, but also how much time you have left on your trip. He’s basically your best guess on the road. He’s not 100% accurate, but he’s the closest thing you’ve got.

Back on project management, we have the same problem. When we start a project we always want to know how it’s going to go, so we plan.  Sure, we plan a little differently, but we end up with the same result.  We plan and come up with an idea of how long we thing it will take us to get there. The interesting part is when your project starts. All my teams have their own GPS system. I use it to see how along they are on their projects. Not only does each time have their own GPS system, but it’s a smart GPS. See, a regular GPS will tell you how much time you have left on your trip if you go at the planned speed. My teams GPS actually figures out what their speed is. And that’s the secret.

So how do you figure that out? It’s all about one simple formula:

distance = rate * time

We’ll get into that on our next post.

One of the things that was missing from the functional set that I ended up needing was the ability to page the list, but through issuing AJAX requests instead of the typical post back.

So I went off and extended the existing model to support AJAX requests, and thought I would share it in case anyone else needed to do the same thing.

I guess the best place to start would be the use case.  So to start I created a control that encapsulates the Paging UI layout and calls I need.  The use of the original control looks like this:

Html.RenderPartial("AjaxPagination",
    new AjaxPaginationViewData
        {
            PageIndex = Model.PageIndex,
            Action = "CondoPage",
            Controller = "Home",
            AjaxOptions =
                new AjaxOptions { UpdateTargetId = "updatedContent" },
            TotalCount = Model.TotalCount,
            PageSize = Model.PageSize,
            NumberOfPagesToEachSide = 2
        }
);

The new AJAX functionality is called similarly:

<% using (Ajax.BeginForm("SomePage",
        "SomeController",
        new AjaxOptions { UpdateTargetId = "updatedContent" })) { %>

        <% Html.RenderPartial("AjaxPagination",
                new AjaxPaginationViewData {
                        PageIndex = Model.PageIndex,
                        Action = "SomeAction",
                        Controller = "SomeController",
                        AjaxOptions = new AjaxOptions
                                { UpdateTargetId = "updatedContent" },
                        TotalCount = Model.TotalCount,
                        PageSize = Model.PageSize,
                        NumberOfPagesToEachSide = 2
                });%>

<% } %>

A couple things to note. You’ll notice that the AJAX control is rendered inside a Ajax.BeginForm. This is because I’m using the Microsoft.Ajax way of making AJAX calls.  This could also be done using jQuery or something else that can process AJAX calls. I just went this way because the scripts are already included in asp.net mvc app when you first create the project.  The result of the AJAX call will be a partial view, and we’ll need to put that somewhere.  That’s where the UpdatedTargetId comes into play. Other things we include in the AJAX control that are not in the original are the Action and the Controller, and some AjaxOptions. PageActionLink doesn’t work with the AJAX control, because we’ll be using Ajax.ActionLink to build the link, which is why I broke it up into Action, and Controller. For the AjaxOptions, we need those to specify the target of the call.

So now that’s been explained, let’s look at the controls themselves.  Here’s a comparison of the original control and the ajax control.

The original is one this way:

<% if (Model.HasPreviousPage) { %>
    <a href="<%=Model.PageActionLink.Replace("%7Bpage%7D", (Model.PageIndex - 1).ToString())%>">Previous</a>
<% } %>

<% if (Model.GetFirstPageToLink() != 1) { %>...<% } %>

<%for (var page = Model.GetFirstPageToLink(); page <= Model.GetLastPageToLink(); page++) {
    if (page == Model.PageIndex) { %>
        <%=page.ToString()%>
<% } else { %>
    <a href="<%=Model.PageActionLink.Replace("%7Bpage%7D", page.ToString())%>"><%=page.ToString()%></a>
<% }

    if (page != Model.GetLastPageToLink()) { %>|<% } } %>

<% if (Model.GetLastPageToLink() != Model.PageCount) { %>...<% } %>

<% if (Model.HasNextPage) { %>
    <a href="<%=Model.PageActionLink.Replace("%7Bpage%7D", (Model.PageIndex + 1).ToString())%>">Next</a>
<% } %>

And the AJAX control is done this way:

<% if (Model.HasPreviousPage) { %>

<%= Ajax.ActionLink("Previous", Model.Action, Model.Controller, new { page = (Model.PageIndex - 1).ToString() }, Model.AjaxOptions)%>

<% } %>

<% if (Model.GetFirstPageToLink() != 1) { %>...<% } %>

<%for (var page = Model.GetFirstPageToLink(); page <= Model.GetLastPageToLink(); page++) {
    if (page == Model.PageIndex) { %>
        <%=page.ToString()%>
    <% } else { %>

<%= Ajax.ActionLink(page.ToString(), Model.Action, Model.Controller, new { page = page.ToString() }, Model.AjaxOptions)%>

<% } if (page != Model.GetLastPageToLink()) { %> | <% } } %>

<% if (Model.GetLastPageToLink() != Model.PageCount) { %>...<% } %>

<% if (Model.HasNextPage) { %>

<%= Ajax.ActionLink("Next", Model.Action, Model.Controller, new { page = (Model.PageIndex + 1).ToString() }, Model.AjaxOptions)%>

<% } %>

The big difference here is the way that the links are generated. The original control simply creates an anchor tag and passes in the url generated by the Model. The AJAX control uses AJAX.ActionLink() instead, so we can have the link support AJAX.

So knowing how the control looks, this is the Model for the AJAX control itself:

public class AjaxPaginationViewData
{
    public int NumberOfPagesToEachSide { get; set; }
    public int PageIndex { get; set; }
    public int PageSize { get; set; }
    public int TotalCount { get; set; }

    public string Action { get; set; }
    public string Controller { get; set; }

    public AjaxOptions AjaxOptions { get; set; }

    public int PageCount
    {
        get
        {
            return (int)Math.Ceiling((double)TotalCount / PageSize);
        }
    }
    public bool HasPreviousPage
    {
        get
        {
            return (PageIndex > 1);
        }
    }

    public bool HasNextPage
    {
        get
        {
            return (PageIndex * PageSize) <= TotalCount;
        }
    }

    public int GetFirstPageToLink()
    {
        return (PageIndex - NumberOfPagesToEachSide > 1 ? PageIndex - NumberOfPagesToEachSide : 1);
    }

    public int GetLastPageToLink()
    {
        return (PageIndex + NumberOfPagesToEachSide < PageCount ? PageIndex + NumberOfPagesToEachSide : PageCount);
    }
}

That pretty much explains how the control is built.

The only thing left is how the interaction with PagedList happens.  For that we look at the action that the control calls.  In this example, we’re calling SomeAction in SomeController, and it would look something like this:

public ActionResult SomeAction(int page)
{
    CachedPage = page;
    var query = GetSearchQuery(CachedSearchParameters);
    var model = query.ToPagedList(page, DefaultPageSize);
    return PartialView("AjaxResults", model);
}

The ToPagedList performs the functionality that is included with the PagedList classes which you can find here.

Let me know what you think, and if you’d like some demo source to see this in action I can happily provide, just let me know.

What is the email address on this card?

Maybe this is more understandable?

or I could swap the email and the site, maybe that makes it easier to read.

I’m getting there! This was suggested by Steven, and I think he’s completely correct.

Let’s start buy throwing up what we currently have so we can see where we’re trying to go.  Here’s a mockup of what a user will see when they search for trades right now.

I have a couple problems with how it works right now.

1. I don’t like that it’s in a grid/table format.  I have to fix that first.  I’m moving more towards something like a list layout.
2. There are some things missing that I would like to be able to do.  For instance, if I just searched for “can of soup”, and I see that Michelle has the one I want, I would like to have a button/link/something to click on that says “I want that!”  Right now the only thing you can do is go look at the trade, or ask a question.
3. Clicking on the owner’s link takes you to their profile, but it doesn’t show you what other trades they have, or trades they are looking for.  That information could really be useful.

I’m sure there are other things I could think of, but for now I’m going to start focusing on these three and build some mockups to illustrate these workflows.

First, getting rid of the grid.

This search list looks a lot better I think.  There are some more features on here then the other one, but we’ll go over those in subsequent posts.

So at this point I’m looking for any feedback.  ANY feedback, good or bad… I’ll take it all.  I really haven’t made up my mind at this point yet, but I think I’m heading in the right direction.

Next post will be about the “I want it!” feature.  Stay tuned!