- Posted by Ian Suttle on November 29, 2008
- Filed under General
Here at IGN Entertainment we're almost always looking for smart and curious software engineers to join our teams. Whether you're a .NET (C#), Java, or C++ programmer we'd like to hear from you. We prefer a bit of experience and a degree, but if you're one of those natural whiz kids continue reading.
Why might you want to work at IGN? I'm biased of course, but we're absolutely awesome ;). We work on a variety of applications including ecommerce, media, file distribution... we cater to heavy spikes of demand (our page loads are measured in millions to hundreds of millions per month)... we're not afraid of new technology... the gaming industry is always changing... flexible schedules, casual dress, competitive pay, good benefits, blah blah blah.
If you're not repulsed by such awesomeness feel free to contact me!
- Posted by Ian Suttle on November 15, 2008
- Filed under Agile | Process
Welcome to part four in our ongoing quest to bring an effective agile development process to IGN Entertainment.
Something we're looking at adding to our agile tool belt is estimating stories using story points. If you're not familiar with story points think of them as an estimation using a relative level of effort/complexity.
When getting started with story points they don't provide you much benefit beyond understanding how one story's effort compares to another i.e. "this story is a 1 and that story is a 13". More on that later. The real value comes as you make your way through numbers of sprints and releases. As you progress you can look back and see how many story points a team can accomplish during a sprint. Naturally, if the team's composition isn't constant the velocity begins to become less accurate. The measurement of story points completed over a given amount of time is referred to as velocity.
Velocity = (Story Points Completed / Iterations)
Example: 50 Story Points Completed / 5 Iterations = a velocity of 10 story points
Velocity is handy as a means of understanding the general capacity of a team. If a team, on average, can accomplish twenty story points per sprint, then you've established a story points budget, and you'd plan for about twenty story points for the next sprint. That might be ten stories or that might be just one story depending on the points associated with the stories. Taking it a bit further, using velocity allows you to estimate a release timeline using some simple math. Consider the following formula to estimate the number of iterations/sprints before a release:
Estimated Iterations = (Story Points / Velocity)
Example: (100 Story Points Remaining / 20 Story Points Velocity) = estimate of 5 iterations
In this example, if an iteration was 2 weeks you'd have a good estimate of being 10 weeks out from release.
There's not a hard-fast rule for how to estimate with story points but we're taking a liking to Planning Poker. The attraction is the estimates are done by the team and not by individuals. Making a game out of it doesn't hurt either :). If people greatly differ in their point estimates the team discusses why and re-estimates until the members of the team are close enough to just take the conservative end of the estimations.
My favorite form of story points uses numbers from what basically equates to a Fibonacci sequence (with some reasonable modifications for ease of use):
The idea is the higher the estimate the more risk/unknown/general the story is. It would seem optimal to have story estimates as far left as possible as they require less effort, are more well defined, and as the major bonus, should allow for a more accurate estimate.
The application of stories points feels very promising to us. Like everything else we add to our process it's not going to be a silver bullet but does fit in with us always looking to incrementally improve.
Have you used story points for estimating? Has your experience been positive or challenging?