Release Planning

How to build an estimated release date.

I had time to reflect on what our blog post would be this week. This was because I just went on vacation with my family. I’ve been going on a summer vacation for decades with my family (yes that makes me feel old but it’s the truth). I do what everybody does when they pack for vacation. You think about what you will be doing and try to pack accordingly. I know fishing will happen and hopefully I’ll catch a fish or two. So I always bring my fishing rods, tackle box and net. We always get a round of golf in so I can’t forget my golf equipment. Last but not least, who can forget about the hot tub. So that means bring a swim suit. 

Look at that fish

Regardless of when I fish or golf or swim I know I need the everyday stuff. We all do. Clothes, shoes, toiletries and don’t ever forget the phone charger. Needless to say I forgot my razor and my net for fishing. Happens to the best of us :).

This dude forgot to pack his razor.

For family vacations you will be required to plan and communicate schedules to everyone demanding information on whats happening. Similar to large corporations that want their Agile teams to give an estimated date for when they think something will be done. That helps with the budget, coordinating cross dependencies, and scheduling upcoming work. Use the tools agile has given you along with your common sense to build the release plan. Check out latest episode above to hear about what you can do with your own team.

Roadmap estimating

Podcast on roadmap estimating

People do estimating everyday without even knowing it. The majority of the estimating is done at a high level so it’s kind of odd when you run across people who struggle with this at work.

For instance, I do this almost daliy in my everyday routine. Just recently I created my own high level roadmap. Two years ago, I was looking at my house and noticed that a section of my cedar siding needed to be replaced. I had no clue where to begin. So I did what most people do and went to YouTube to get a feel for how difficult it was. I came to my own conclusion that it was a couple day at home project for myself. I just had to remove the old siding, buy new siding, hang the new siding, prime it and than paint it. YouTube was right. It was easy.

Last year I noticed that I should replace the cedar siding on the other side of the house. The work indeed would be more dificult with more edges and the need to do angled cuts. I figured I could tackle this. I said to my self: “few nights after work”. Much to my own delight it didn’t take that long. It was a semi weekend weekend with a few nights after work commitment. Much to my chargrin, the angles were super hard to cut. On the bright side of things I was able to utilize my experience from the last time I did the siding.

I gave this job a medium estimate

When spring finally arrived, I looked at the house once again to determine I wanted to update the siding by my garage. This was going to be the biggest job I would take on to date. The job required longer pieces of siding and more angles. I was trying to talk myself out of doing the work, but I knew I really should. I figured this would be a full weekend and maybe a few nights after work. Now what does this mean to me? With how short summers can feel and trips already planned. I’m planning on tackling this job in the late summer after vacations are over and the fall is fast approaching. I knew if it was a smaller job, I would have taken the work on now.

Agile road map estimating is similar to making decisions in your own personal life. Listen tour latest podcast where we give some great tips and tricks about how to estimate your road map for your company utilizing the team.

Team Estimates

Learn about effective team estimates

When thinking about effective team estimates, there isn’t a whole lot of ideas that immediately come to mind in the real world. After sitting in a sauna and racking my brain for a good blog post, it came to me. If you have ever been talked into or convinced by a friend to join a team triathlon event, then this will resonate with you. I will still say this, that you won’t need have participated to get this example.

Creating a pace

Now lets get into the meat of the post. Creating a team to compete would revolve around picking specialist. You would have someone on the team who is good at swimming, biking and running. Its easy for the individuals to come up with a estimated time of completion based on each individuals pace in each event. Now if we are to compare an Agile team to this. You would take the same approach with someone that is really good at developing the User Interface and a person who excels at writing amazing backend code. To round out the team you would also want a person who is a DevOps guru. Dare I say that this could be compared to the blueprint of building a dynasty much like the New England Patriots in the NFL.

Wild Card

Now lets throw a wild card into the team triathlon example. A email is sent out to participants that the the people doing each segment will be done at random and only announced at the start of the race. How would the team go about determing their estimated time of completion. You would start at the swim. Assuming each person has swam before, you would have a gage for the time it would take. Human nature leads us to negotiating to the middle, but that should be avoided. The higher estimate should win out. Now based on that understanding the team would go through each event and determine pace to help ballpark completion time. Much like Agile teams, there is this desire to estimate lower and not estimate through the lens of the person who skillset is weakest in that area. Yes, its possible the estimate is too high for some of the team, but the great part about the estimates is that it will even out over time. It will help baseline your sprint commitments (forecast) with the team to be more consistent. In the triathlon example the team may luck out and gets their events they specialize in but and unlikey outcome. Much like development, the stories won’t align perfectly with the skillsets. Most scenarios aren’t that well played out, as teams could have tons of UI work that is most valuable items in the backlog. Ideally you improve over time as specialist will help the others improve skillsets by paired programming or mob programming. Check out our lastest epsiode where we address effective ways to improve your team estimating.

Battle of the Estimates

What is the right estimating technique for you?

In the battle of the estimates we compare different estimating techniques that Agile teams can use. I spent time sitting down and enjoying a adult beverage and brainstorming on what real life examples compare to this. It took a while to come up with something. Then I realized that comparing estimates is like comparing travel options when traveling to Europe. You have many options of travel and each one has its own benefit.

Choosing to fly in
Choosing to fly in

If you are looking at the travel options when you arrive in Europe you would get to choose between: air, train, car or sometime ferries as transportation options to different cities. Often when looking at air travel in the US it is by far the most efficient means of transportation over rail. However in Europe that isn’t the case as getting through security can almost eliminate any advantage over rail. Often trains have advantage over planes because the terminal tends to be in the heart of the city vs the airport being 30 miles out. Now if you had to travel a remote tourist destination then a car may be your best option as most rails and airports are not located in close proximity. You may be asking yourself on how this ties into picking the right estimating technique for your team. Well it comes down to where and what your team is most comfortable with. Much like modes of transportation, there are different varying results for estimating techniques to help further develop your team into rockstars. Check out our latest episode above where we give our own opinion on what our favorite technique is.

My team does agile and all I got was this lousy t-shirt

Short podcast on estimating wrk using t-shirt sizing

People t-shirt size in their daily lives all the time without realizing it. I do it on the weekends. Every weekend I always make a mental list of what I want to accomplish. In the spring time my lists gets long. Sweep out garage. Organize garage. Put snowblower to bed. Sweep deck. Take patio furniture down from garage rafters. Put out the hoses. Put out the big flower pots. Plant flowers. Pick up the lawn. Fertilize. Clean the windows. Clean the screens. Uncover the air conditioner. Thats a lot things to do and some are easier to do than others or just take longer. The main thing is is I don’t do them all at once. I put the puzzle together in my brain and figure out a handful of things I can get done in a weekend. I don’t know how long it actually takes to do any of these chores, but I do know that sweeping out the garage is smaller than putting out the large planter pots (those suckers are heavy).

T-shirt sizing work for your agile team shouldn’t be any different. Try to compare the work to other work and give it a size. Then move along. Don’t fret. If the replacing of the soffit vents turns out to be harder than you thought (I had it pegged to putting out the hoses) no big deal. The soffit vents got replaced and live moved on.

Bar picture of hiding from wife estimates
Bar time estimation.

Time waits for no one

Discussion on why estimating with hours is bad.

This has happens to all of us. You come in to work and turn on your computer. You open up your email to see what number of unread emails awaits you. Once you have managed to find you way through emails, you check your calendar. First thought that comes to mind, is wow, a fun packed day of back to back meetings. They don’t overlap so everything should be ok. Turns out it’s not ok because you are 5-10 mins late for every meeting. How can that be? Two meetings ran late because other people came late so the meetings started late. One meeting ran late because there was no solid meeting agenda and the meeting just kept going. All the other meetings ran their full length but you don’t get to snap your fingers and arrive at the next meeting 2 floors down or on the other side of the building.

Estimating work in hours is just like having back to back to back to back meetings. There is no time to breathe. No consideration for context switching. No room for any adjustments. Especially no consideration for walking time to get to the next meeting. On paper it looks perfect, but at the end of the day things were a blur and you were late to meetings. At the end of the day you let the clock dictate what you schedule looks like and not what you think is the best.

Poor guy pays more attention to time than to what he wants to do.

Teams work in similar ways, when pushed for perfection on paper things don’t result the way you would think. That’s why you should keep things simple and easy to reference. Although it may be seen as a simple tactic, when teams buy into the goal and tell you what they can accomplish, it certainly has better outcomes in general. Check out our latest episode about how hours in estimating aren’t as beneficial as you would think.