Category Archives: Software Development

Adventures in Story Points

Story points are a corner stone of the agile development process, giving a key piece of information from those that implement the story to those that decide what gets built. It’s not the only piece of information that goes into planning at the product level, but it is the most important from a process point of view. Story points don’t just estimate how long a story will take, but bundle in estimates of technical risk and uncertainty. From a PM’s perspective two stories can sound the same, but end up with a large gap in the estimated story points. This could be because the engineers are deep within the code base that pertains to one story and not the other; and thus feel more confident about exactly what needs to be done. Or it could be because some things sounds easy to implement but aren’t. In my days as a consultant I’ve seen story points described in a few different ways:

  1. The number of days an engineer thinks it will take.
  2. An estimate of the size and complexity of a story; time estimate + risk factor
  3. A comparison of how big one story is to another; story1.size == story2.size

The pure agilest will tell you that story points are #3, but in the real world its hard to compare the size of a story with another without giving an inherent engineering hours estimate. Where teams get in trouble is when they start measuring their velocity from one sprint to the next as a ‘team performance metric’. If engineers get hounded when their velocity dips they are incentivized to either over-point or give points in terms of time, aka method #1 which is a flawed way of pointing a story. Points are for size which why we estimate hours for story tasks during sprint planning as well, because you have the best ability to judge how long a task will take right before you start it. If you point a story, and it sits for six months in the back log and then comes out and the assumptions around implementing it have changed, like say it was pointed assuming a certain library would be available and now the legal team has nixed using that library, then you’re going to be in trouble when it comes to measuring your velocity. Ideally you’d re-point anything that has sat around that long, but unless someone flagged that story as dependent on library xyz then the team might miss the fact that it no longer has accurate points.

A team’s velocity will change over time. So using story point velocity as a golden ruler of performance will make for a lot of unneeded stress. As a project moves from laying the architectural framework, to fleshing out all the details the team will gain or lose velocity depending on everyone’s abilities, throw in team member churn, ramping up new members, triage meetings to support legacy code, taking time to fix bugs and seeing a downward velocity in story points per engineer per sprint isn’t unheard of.

So how should you use story points? There is no perfect solution. And that’s what agile is all about. You have to find the right implementation for your team. How’s that for copping out of a decent answer? On a more specific note I tend to favor deciding how many points an engineer should take in a sprint first, and then using that as a measuring stick for how big a story is. As an added bonus to help keep story points consistent over time I find it helpful to pick out stereotypical stories during sprint closing as a reference for future grooming.

Story points are an integral part of the agile development process, and it’s one that is often contentious.  I’ve found it helps to have a written definition of the teams interpretation of story points (a long with all other process terms) to ensure everyone is on the same page.  So, don’t fall into the trap of militant Points per Sprint velocity measurements or bickering about what a story point means each print. In the end, story points are what you make of them.

Tech Strategy – Change the Game Part 2

The large storage future smart phones?


What would some use cases be for a smart phone with lots of storage space? The first market that comes to mind is the developing markets where cell data is expensive and slow for most people. The second is just comes from enabling better customer experiences through a faster user interface. The third is in gaming and video streaming.


Think of an app like Yelp, if yelp could store it’s top N restaurants in the current city for the user, then they could zip through the interface in their search for a bite to eat instead of waiting on a network call every time they wanted to see the next 10 restaurants or wanted to switch category filters.

Or Amazon prime instant video, enabling people to download HD content at home and watch it on the road without burning their battery life and data plan.

Or maps that don’t have to reload tiles each time, and could cache the users common routes on phone so the user gets their directions faster and with fewer privacy concerns.

A business user could take their entire email history with them and be able to search through it while on a plane.

The downside is that phones are lost/stolen often and that could create more of an information security hazard, but I’d wager that if people are willing to turn their phones into credit cards, car keys and garage door openers then they shouldn’t be afraid of a thief seeing which Amazon movies they have downloaded.

Higher storage devices would enable streaming like services that don’t always need an internet connection. The app could download a wide selection of music onto the device overnight and provide a similar playback experience to what there is today. Or if piracy is a concern the app could just store 80% of the sound range and stream 20%.

The bottom line is that larger storage capacity is cheap, and could enable longer battery life and better use experience in the hands of a clever development team.

Learning Ruby

The last time I tried to learn Ruby my Dad died.


The two were entirely unrelated, but when I think if Ruby I still associate it with Cancer and dying. But since then I’ve also finished my CS degree and played with lots of different languages. And as I’ve evolved over time as an engineer I’ve wanted to find a a quick way to build an API or website, and while node/express has been straightforward I’ve always wondered how it compares to Ruby on Rails.

So with that in mind I’ve set out to learn Ruby again. I’m starting with the site RubyKoans ( because I saw it recommended by a rubiest as a way to transition from other languages.




My dive into Ruby evolved into learning Chef at work  to automate deployments for a private cluster and also creating end to end integration tests of that cluster.  Ruby is very fast and flexible, but a pain to try to use on Windows.  So I ended up doing all my work in a Linux vm and getting better with all the command line tools in the process, I’m not sure I’m ready to use Ruby for a side project but this work project really showed the flexibility of the language.

Of great important is that no one died.

Developer Tiers

Through my time as a software engineering I’ve come to understand the craft of coding in a new light. As with the light bulbs over peoples heads in cartoons, it starts with an idea.

Which is to say it starts with one persons vision.  They then share that vision with other people that will help them build their vision, and if that vision is solid everyone will be developing the same idea.

Unsurprisingly different developers think of an idea differently, and I think it leads to tiers of developers that, all other things equal, separates the good and the less good.

The tiers come from looking at an Idea from different view points. First is the view point of how to implement an idea.  This is the type of stuff that shows up on job descriptions and is all about basic technical skills and ability to make something.

Tier two adds the ‘How to maintain’ the code base point of view.  In the rush to add features documentation and unit tests often get bumped but if the Engineer has the maintainers viewpoint they are still able to write code that doesn’t incur technical debt.  It’s self documenting, decoupled, re-usable and easily followed.

After that is the “How will the users actually use, or want to use, this software product”.  Sometimes the user is another service, sometimes it’s a consumer, sometimes it’s another developer.  At the end of the day it’s really important for developers to know who is using their product and be thinking about them. For any given piece of functionality there are N different ways to implement it, all with tradeoffs in speed, security, reliability, usability etc.

Keeping the User, Maintainer and Implementer viewpointS in mind while designing ensures that the implementation chosen builds the most present and future value possible.