Being that we’re all human, sometimes things happen that might disrupt a project’s “normal” flow: we get sick, we take a vacation, we put in extra hours to make a deadline, etc. When life happens, it’s good to reflect that in Tracker so we can depict the most accurate Velocity, and thus plan our iterations using the most true-to-life data possible. In Tracker, we do this by using a fun little feature called Team Strength (TS).
How does it work, you ask? It’s pretty simple: if you look in a project, you will find a TS icon located in the far right of every iteration header. If you click that little guy, a box will appear that allows you to enter in a percentage to depict what level your team was operating at during that iteration.
Now to be clear, this isn’t something you should typically find yourself adjusting every iteration; if you are, there might be bigger problems at hand. Moreover, this feature should be used when the team has had a major hindrance (or assistance) that affected the team’s “normal” productivity by a measurable and quantifiable volume. As previously mentioned, this could be because of vacation, because half the office contracted the flu, because you have some interns join over the summer, etc. Essentially, we’re trying to avoid “punishing” your Velocity when these situations occur, and Team Strength lets us do that.
So let’s get into some examples to bring this home. Say you’ve got a team of 10 developers, four of whom sign up for the same conference and won’t be available for an iteration. You’ve lost 40% of your workforce, which is going to directly impact the number of story points that can be produced that iteration. Not a problem—simply edit your TS to be 60%, which tells Tracker that you were only operating at 60% of what you can (and do) normally operate at. Let’s also say that with these six devs, the team was able to complete 6 points for the iteration. When that iteration rolls over and those points move to the Done panel and are calculated towards Velocity, they won’t count as 6 points—they’ll count as 10 because you told Tracker you were only operating at 60% that iteration (if you can complete 6 points with 60% of the team, you would have theoretically completed 10 with 100% of the team, thus Tracker gives you 10 points instead of the actual 6). By using TS, your Velocity is unaffected by this temporary fluctuation in the team and the next iteration won’t be planned with fewer stories because you had a temporary hindrance.
Now going a step further, let’s say that you’re working with two-week iterations but the four devs only spent one week of that time at the conference. In that case, instead of entering a TS of 60%, you’d want to cut it in half and reflect an 80% TS—pretty simple stuff! Assuming you still only completed 6 points for the entire iteration, Tracker would calculate 8 points for the iteration versus 10 with a 60% TS. (Tracker knows that if you can complete 6 points with 80% of the team, you can complete 8 with 100%.)
Alternatively, let’s say your team takes on four interns for the summer. They’re all up to speed and are contributing approximately 40% more to production, but you’ll only have them for a few more weeks. You anticipate that when they leave, production will slow back down. You can reflect this by entering in a TS of 140% and as a result, you can avoid overinflating what will be planned in the coming iterations, after they’ve left the team.
What if you’ve started a new project and therefore have no history to draw on for accurate Velocity? What would your project look like if you were to hit a bug wall, and your Velocity took a hit as a result? Sometimes it can be helpful to predict the future and have a visual representation of what your projects would look like under a variety of conditions (e.g., how would those conditions affect the backlog?). Velocity Override allows you to do just that—see what your iterations would look like if your current Velocity were a certain value.
To use Velocity Override, simply enter your Velocity value in the upper left, below your project name. A box will appear that will allow you to enter the hypothetical Velocity of your choosing. After entering the new value, you will see your Backlog adjust as a result.
It should be noted that there’s not a way to manually set your own Velocity, as Tracker was designed to calculate this for you and thus plan your future iterations out based on this. Velocity Override’s role is to facilitate a temporary view of your project under hypothetical conditions, so that you can see what your project would like if your Velocity were a certain number; it never replaces your actual Velocity. When you’ve edited your Velocity using this feature, no one else will be able to see the updated project view but you, and when you refresh the page, your Backlog and Current panels will return to normal.
Happy Tracking!
Category: Productivity
