Rusty Divine

Live, Love, Learn, Teach

Do you have an iteration or sprint calendar?


Does your team sometimes lose track of the important mini-milestones in your iteration? Our team has daily stand-ups and a task board, but we sometimes forgot when we were supposed to get a release ticket created or if we were promoting this week or next.

We created a simple iteration calendar and pinned it up at our stand-up wall. Each day we moved a red pin to the day we were at. It was a simple hack to help us remember to do all the little things, which was extra important on our team because each member took a turn with setting up the necessary meetings and doing the actual code promotion.

If you would like to learn more about how we managed our iterations check out module 5 of my Pluralsight course on Introduction to Working the Project.

10 Years of Blogging

My first blog post was ten years ago! After blogging for ten years it is a good time to reflect on what blogging has meant to me.

I think we could do a quick test if you would help me out. If you see this post within a week (by June 29th, 2015) leave a comment. It can just be ‘I was here’ or something similar. I’m guessing I get 0 comments, but maybe as many as 3.

The first thing that says to me is that you can blog for ten years and not have any followers. I didn’t expect that when I started, but it hasn’t stopped me either. I blog to entertain and to teach, but also mostly its selfish so that I can develop my ideas more fully or find a reference to how I did some complicated code just by searching my own blog. Even without any followers I expect to be around ten years from now, too. Blogging is like jogging – it’s exercise for my brain – and like jogging, people aren’t very interested in watching me exercise –). Unlike jogging, some of my blogging content is actually useful to people who’ve encountered a similar problem that I’ve solved in a blog post.

My most popular post in these 10 years is How to encrypt a password reset email link in asp.Net mvc with around 7,000 views and the runner up is No One Knows They Want Visible Solids in Their Spaghetti Sauce with about 5,000 views.. Ok, that second one really surprised me. It looks like almost all of the traffic is from Tuesday May 27, 2014, and the main referrer is from the second bullet point on this Sweedish blog post, I kinda wonder if the author intended to link to my post?? The top-viewed post gets a lot of search traffic and I think it’s the accepted answer on a stack overflow question, or at least someone references the article for how to do it.

Have I made any money? Yes! I made about $2.50 when my good friend actually clicked on the Buy me a beer button on the sidebar. I have not received a single check from Google or any other advertisement. I also have not been given any free books or software to review, although if someone does read this I would totally do that!

Every time I interview for a job I do mention that I blog, and that generally gets a positive reaction even if the company never goes to check it out. It’s just like saying, “I care enough about my craft to write about it.” I would recommend blogging to any software developer just for that bonus.

What could I be doing better? I like to look to role models like Scott Hanselman and Scott Adams who do really well at teaching others by clearly explaining ideas and being multi-dimensional by blogging about lots of life experiences. Hanselman does a great job trying out cutting edge technologies and giving people quick guides with screen shots to how he got that technology to work. Adams has his systems philosophy where you throw goals out the window and just follow a process every day until one day you reach and surpass any goals you would have set. I could be doing more like Hanselman to show what I know, and I could be doing more like Adams to set up a consistent blogging schedule so that I have some content that followers would stay engaged with.

Agile Story Pointing Benchmarks

We use story points to estimate how much effort a given story will take. We have found it reduces optimism inherent in estimating with hours because it encourages the team to use comparisons to other stories instead of imagining how long it will take. When we do estimate with hours, we typically think about the happy-path, and really, that’s OK.

Consider a two-week iteration with 10 stories. Maybe 6 of those stories take the happy-path and are completed pretty much as expected. Two stories are actually a lot easier and are completed faster than expected, but the other two take significantly longer than expected. The problem is, we don’t know which 2 those are in the beginning, so there’s no way using hours to accurately estimate. Instead, if your team is fairly consistent, you can use points to know that in a given iteration you can complete 30 points of stories. A few of those stories turn out harder than you expected, but that’s always the case. Everything evens out in the end, or at least, evens out more consistently in the end.

But, to get this ball rolling your team really needs a good common understanding about how to compare two stories to know how much bigger one is than another. We use the series of sizes like: .5, 1, 2, 3, 5, 8, 13, 20 –> we rarely let a story stay at 13 or 20 without breaking it down further because at that size we’re getting into something we’re not sure someone can complete in one iteration. You can start your team off by choosing a very familiar story that can be your 2-point benchmark, and one that can be your 5-point benchmark. Then, every story you consider can be compared to those two benchmarks and your team can collectively decide where in the range the story fits. Typically even non-developers can point development stories and developers can point non-development stories as long as they can fit it into their mental picture for how much effort a story like that would take.

Our team has experimented with taking it one step further and creating descriptions for each of these stories. This is still experimental and the general feeling is we would need to shorten this list by about half to make it more concise:

.5pt story

· Small bug fixes with no foreseeable risk and small JavaScript tweaks

· Small view updates; no tests affected (spelling; remove field; add label; move field)

· Business meeting that requires less than two hours of prep work

1pt story

· Bug fix with low-to-medium difficulty/risk, but well-understood, may affect a few tests

· Simple well-defined task (new validation; make field read-only when; fix/improve CSS)

· Research task time-boxed at about a day (what if scenario; will this work)

· Business meeting that requires two-to-six hours of prep/follow-up work

2pt story

· Bug of medium difficulty/uncertainty, or several tests affected (unexplained JS errors; AJAX)

· Understood task spanning >1 layers/screens/tables (validation rule server & client side; repetitive but tricky; significant data load script changes)

· Try small prototype (performance improvement; what if scenario)

· Business meeting that requires both significant prep and follow-up work (6-to-12 hours)

3pt story

· Bug fix of medium-high difficulty, significant uncertainty, or many tests affected (concurrency;

· Very simple screen or feature (system functions; nightly jobs action)

· Task spanning multiple layers/screens with one-or-two business rules to modify

· Significant updating of existing documentation (UCP; user manual; tech document; workflow)

· Multi-day research tasks (investigate one-to-two COBOL programs; new framework/tool)

· Business meeting requiring 2-3 meetings or >2 day research/analysis

5pt story

· Bug fix of high-difficulty, high uncertainty, and probable course changes (fix & refactor)

· Design & implement new feature, service, or framework (toast; branch-wide; JS test framework)

· Research & implement performance improvement (batch update via sproc; profiling)

· Documentation branch-wide (style guide; user manual)

· Series of 3-5 business meetings with analysis and design (pink sheet; COBOL workflow)

8pt story

· Implement a new feature that affects most/all of the site (granular security; table logging)

· Refactor a significant amount of code (funding section page, database/code renaming)

· Implement a screen from CICS (estimate adj.)

· Comprehensive documentation (site-wide user guide, technical specs)

· Significant research that will take most of the iteration for one person

13pt story

· Design & Implement an automated process/service (prod>test data move)

· Significant research task that could take all of an iteration for one or two people

20pt story (Consider if this story can be broken down into smaller stories)

· Large research task that could take an entire iteration for two-or-three people

· Very complicated refactoring

· Create and configure a new project solution (n-tier, nugget packages, tests, basic gui)