Sticking With It

In the prior century I made several failed attempts to read the whole Bible. I usually quit because I found the language tedious to read and hard to understand. (That, and a lack of spiritual maturity.) I had tried the King James and the New International versions. I finally bought a study Bible, one of those with lots of footnotes, in a modern translation. Since I was having so much trouble with the wording and reading, I picked a translation that was easy to read, a dynamic equivalence translation -- NLT. It took three years to make it all the way through, but it was very rewarding.

I'm now attempting a read-the-Bible-in-a-year program in a different translation. This time I picked a balanced translation, Holman, backed up by a number of formal equivalence translations, chiefly NKJV and NASB.

There are many different approaches to reading plans. I picked a chronological plan, which I thought would be neat. And it is at least a little neat. I'm hoping that reading the whole thing in a more compressed time frame and chronologically will give me another perspective on the whole thing. Less time will have elapsed from one book to another.

This time around, though, I find the reading much less enjoyable than the 3 year deep study approach. It's a lot more reading and a lot less studying. I would recommend the reading through in a year approach to someone only after they have done it the other way.

Question

What has helped you stick with it and read the whole thing?

My Approach to Estimating

I did some research on using function point counting on an XP project many years ago. A few people remember that paper and occasionally I'll be asked what approach I recommend these days for estimating. There is a lot to like about function point counting and it can be useful on an agile project for estimating a whole project (but not an iteration for reasons explained in the paper).

Story Points and Planning Poker

The best approach for estimating user stories on an agile project is planning poker cards, small stories, estimating regularly, and keeping a small set of good (well estimated) stories visible. What I mean by keeping some standard stories visible is having a BVC (or just story cards left up on the wall somewhere) for those stories that went well, that everyone agrees it was a good 1 pointer or 3 pointer. "How does this story compare to that one?" is a common refrain.

Estimating regularly (weekly or at least every other week) keeps the approach and the "standards" fresh on everyone's mind. Have a regularly scheduled (standing) meeting on the calendar.

I don't get any more complicated than that. That's good enough. It's quick and requires little special skill. Well, estimating with points and planning poker is a skill that does need to be learned, but it doesn't necessitate a class, a thick set of rules, or a software estimating tool of any kind. Sure, a class or some reading can help, but it's not necessary.

Bootstrapping

For bootstrapping an estimating process for a new team or a new project, I like Steve Bockman’s Team Estimation Game or the less formal approach I used on a project in the early 2000's which amounts to little more than collaborative sorting of story cards into simlarly sized piles. James Grenning describes another version of a similar activity.

Question

On a related topic, tell me, do you have only the developers participate in estimating or does QA participate too?