Monday, January 30, 2017

Getting Good Estimates


We use Microsoft Team Foundation Server for tracking our activities during our sprints.  You can jump over there to read up a little about this if you have never seen it.  One of the areas that we are focusing currently is estimating how much work we can realistically get done in our two week sprints.

We started tracking our work to the half day level a few months ago.  As an aside, there are several schools of thought on how to track this type of activity.  You can track by the hour or the day is one example, and there is even a difference of opinion for how to track items that will take more than 1 day.  Some folks say just use the best estimate you have, and others say always round up, and even debates about using the Fibonacci sequence for scheduling.

Where we have focused has been on two areas:
  1. Simply creating a task for everything we need to do.
    1. An example here is a couple of our folks are working on documentation for a new feature we are trying to start.  Each of them devoted X number of days to get the documentation done.  So far, so good.
    2. The problem was that the entire team needs to read, review and respond to the documentation.  We had not devoted any scheduled time to that work in the past.  If we each need 1 or 2 days, that is a large percentage of a 2 week cycle.  We learned our lesson in the past so we devote dedicated time here.
    3. Other examples would be blocking time for code reviews (more time if we know a particularly complex change will be attempted in the sprint), time for hackathons, etc…
  2. Once we have those estimates, TFS gives us a summation of how much time we have and how much work we are adding to a sprint.  If we have 100 engineer days, for example, we should not try to take on 120 days of work. 
    1. We have tried this in the past and it seldom works.  The extra work simply gets carried over to the next sprint, but having that long list makes prioritizing difficult. 
    2. Plus, if we have a work item that partner teams need done, the state of it should accurately reflect when a change would be expected.  By pulling it into the current 2 week cycle, stakeholders may reasonably expect a change within 2 weeks.  We have worked to avoid this situation.

So now we have the correct number of work items, all with our best estimates attached on the first day of the sprint.  We take the highest priority items in first.  (This assumes we have an accurately prioritized back log of work items, which we have).  So far our burndown charts show that we have decreased our range of estimates by about 75% - we are 75% more accurate now than 2 months ago.  We'll keep iterating to get this number more accurate over time.

Questions, comments, concerns and criticisms always welcome,
John

Tuesday, January 24, 2017

Sprint Planning week


We follow an Agile process here at Tableau and one of my roles in that is scrum master.  Those links are pretty good overview sites if this is not familiar to you.  Jump over there and read a little about this if you want.

We follow a 2 week sprint cycle here and this was our planning week.  Nothing too out of the ordinary with this - we decide what work items we will complete in the next 2 weeks, assign out some of them to get started and decide what we will demonstrate  at the end of the cycle.  The hardest part of this is usually deciding what to demo to everyone who is interested.  In this cycle, we want to demo a tool one of the testers wrote that generates random data that follows a desired distribution, and we have some cluster work we also want to show.

For me, the hardest part as scrum master is usually trying to find a room in which to meet :)  We moved into a new building at the beginning of the month so getting a room this time was a bit easier since the rooms are mostly unbooked right now. 

For the next 2 weeks we will work on the items we decided to do, update our progress daily and meet daily at standups.  One new tactic we are trying for standup meetings is to update per project item, rather than by person.  In the past, each person on the team has provided an update for what has happened for that person in the last 24 hours, but we are changing that to be more project based.  So far it is going well.

Again, nothing earth shattering here but I wanted to give a very broad overview into a typical day at Tableau.

Questions, comments, concerns and criticisms always welcome,
John

Monday, January 16, 2017

Not making a change that would have made no sense


Like most applications, Tableau supports several languages.  Here's a quick screenshot of what we currently offer:


No big surprise here: we keep a list of all the text (strings) that we use in our application in a file, and localize (translate) them into each language. 

For instance, we have the color "Blue" in our UI in many places.  In Spanish, that will be "Azul".  So we have a file that has a string number (let’s say "String1447") and that string number points to several translations of "Blue." 

What we try to do - and this is pretty much the standard way of providing multiple language support - is to never refer to the text "blue".  Instead, whenever we want that word to show, we ask for the correct translation of "String1447" - which in English will be "Blue," in Spanish "azul," etc… 

So if I am looking at a color palette on an English machine, when I hover over the Blue color, the UI asks for the English translation of "String1447" and shows me "Blue." 

I was looking through our string table the other day to see if there was any way to make the process of using it more efficient.  One thing that jumped out at me was that we have several different entries for "Blue" (and "Green" and "Brown" and other colors).  That struck me as odd - why do we need to have all these duplicates?  If we just had one string ("String1447") for Blue, we could have smaller files, less build time, less confusion with knowing which string to use and so on.

So my first thought was to remove all the duplicated strings.

When I looked a little deeper though, I noticed that each color palette we have has its own list of colors.  An example would be the Summer palette.  Blue is near the bottom on my machine:

Another instance would be the Tableau 10 colors:



In the strings file, each color palette has its own list of colors.  There are 8 colors listed for Summer and 10 for Tableau 10 which makes sense.  If I am working with the Summer palette, I would naturally want to use a string name of "Summer_Blue" or similar, naturally want to refer to "String_Summer_Blue" or similar.  And if I was working with the Tableau_10 color palette, I would want to use "String_Tableau_10_Blue". 

My original plan was to replace these with something like "String_Just_Blue" (heh) or "String_Blue" and simply use this string everywhere that we need.  But that plan was shelved pretty quickly since it would make our strings table hard to read.  If the list of 10 colors for the "Tableau 10" palette only listed 6 (because of duplicate strings being removed) then everyone would find it confusing.

So my investigation into making files smaller here would have resulted in a system that is more confusing than what we currently have.  So I am not making this change and moving on to other work.

Questions, comments, concerns and criticisms always welcome,
John