An old gem…

I was digging through some of my old files and ran across this old gem. This is a javascript function that will take an email and obfuscate it by creating a series of methods that create the mailto address on the fly. This is to thwart crawlers and is amazingly effective, even these days, as most crawlers don’t process javascript effectively.

Check it out:


​There is a common misconception, especially among those new to Agile/Scrum, that Story Points are just another way of measuring how long work will take and can be easily swapped out with hours. A common mistake new Agile/Scrum practitioners will make is to hand out a matrix that new practitioners can use to easily map the hours of old to the new points system. This approach entirely defeats the purpose of story points. ​

​​Old Way

​New Way

​2 hours
​1 point
​4 hours
​3 points
​8 hours
​5 points
​16 hours
​7 points
24 hours
11 points

Don’t do this…

Why Use Story Points?

Estimating work using story points solves the age old development problem of having different people write the code than those who estimated the work. For example, if you have a tenured, senior level engineer that estimates the work for a given project or sprint then a brand new engineer, fresh out of college, the new engineer is very unlikely to complete the work in the estimated timeframe, even if the senior level engineer padded the estimate to account for this. The problem is that we tend to be only moderately good at estimating things for ourselves and tend to be terrible at estimating them for other people. This is why most software projects and other forms of construction are often late.

Story points give us a way to measure work such that the experience level and speed of the person doing the work does not have a material bearing on the estimation process.

Story Point Basics

The hardest thing for new story point estimators is getting their head around the fact that story points do not measure duration. Instead, story points are used to measure size. By measuring size engineers are able to find a common ground that they can all agree on, even if it will take each person in the group a different duration to complete a task of the same size. Let’s explore with an example.

Story points measure size. For example, 1 mile. Minutes (hours with code) measure duration, or the amount of time it would take you to run 1 mile. Bob is not a very good running and it takes him roughly 15 minutes to run 1 mile. Swathi, on the other hand, is an excellent runner and can run 1 mile in just 6 minutes. The size of the task is the same but it takes each runner a different amount of time to complete the task.

If you translate this concept to software the team starts by forming an agreement for the size of various size tasks (more on this later). For example, adding a text field to a page may be 1 point, adding a new page may be 5 points, and adding a brand new user role may be 13 points. Despite the fact that each person on the team will work these points at different speeds the team has a common estimate for the size of the work to be done. They can now use the amount of work, as measured by size, that they completed in past sprints to determine how much they are going to be able to work in their upcoming sprint. By measuring size each sprint the team can take out the variable of how long it will take each person to complete a given task and instead just focus on the size of what a team can complete in a set timeperiod, their sprint.

This approach is something that tends to be off at first but as teams get used to each other and get a better common relative size reference, estimates dramatically improve.

​Fibonacci Points

To estimate teams typically will use Fibonacci points – 1, 2, 3, 5, 8, 13, etc. By using these numbers it gives better relative size between each point choice, making it easier to compare the size of things to one another. For example, using a 1-10 scale it is very hard to say whether a 6 is a lot or a little different than a 7. But with Fibonacci points it is easy to say that a 3 is roughly 50% larger than a 2 or an 8 is roughly 40% smaller than a 13.

Planning Poker

Planning poker is a common practice, especially for relatively newly formed teams. Once teams become good at point estimating they will often skip planning poker and just assign estimates out together. This proces starts by everyone getting a set of cards with Fibonacci numbers on them. A team member reads out a story to be estimated, along with acceptance criteria, then each member picks a card from their deck that they feel best represents the size of the story. Once everyone has made their selection the team compares.

If there are discrepancies the team takes the time to hear why team members feel the size they applied is justified. This is often done by looking at the highest and lowest first, then working inwards. The team must work together to arrive at a common agreement for the size of each story. Throughout this process the team can always revisit a story if the relative sizing of other stories prompt them to rethink how large a prior story was. Note that this process is often very bumpy and takes longer when teams are newly formed. The better teams know each other and the longer they have been together, the smoother the process and the better the estimates.

Happy estimating!

Management’s Role in Scaled Agile

We are currently undergoing a transformation from a waterfall hybrid (I call it Water-Scrum-Fall) to a flavor of Scaled Agile. As we are navigating the waters of such a large effort there are a number of questions that have arisen. Most have been well covered in the many online articles about such an undertaken. However, there is one that has been very vague and hard to find a lot of prescriptive information on: the role of management in a scaled agile world.

It turns out there is a good reason: the role of management isn’t as central of a role in scaled agile as it is in waterfall. The day to day planning, execution, and corrections are now handled by self directing teams, taking the manager out of the middle of the day to day mix. But this doesn’t mean the manager’s role is diminished…

The role of the manager is still to help the organization reach its goals. This just happens in a different way in an agile world. Instead of directing day to day traffic the manager takes on more of a servant leadership role, helping to enable teams to be successful.

Depending on your organization, your staff, and how you are structured the additional roles of management will vary. Who reports to the manager? Is the manager a coach as well? What KPIs should managers be tracking? What is the role of the manager in escalations? These are just a few of the many questions you’ll need to address to determine the role of the manager in your newly minted agile organization. This is one of the bigger hurdles to get alignment on but once you do adds a great deal of clarity and peace for your managers staring this transition in the face.

Here are some links that we have found that can help guide you. We have yet to find any that are as prescriptive as for more central roles to Agile, such as the Scrum Master or Product Owner:


Good luck in your transformation!