Monthly Archives: January 2008

Jan 14 0 Responses

An Explanation and A Mea Culpa

So here I go, another member of the unwashed masses throwing his hat in the blogger arena. I know there are tens of thousands of blogs and bloggers already out there on the web, but I’ve yet to find a blog that is really geared to people like me. I don’t work for a Silicon Valley giant or an independent software vendor, and I’m not a consultant. I’m like most of you. I work for a mid-sized privately held company that on its best days will win a fight or two against the big boys.

We have an average sized development team of about 15 programmers, and I wouldn’t trade for any of them. They are all ridiculously smart, embrace constant change, and are always learning something new. In order to compete with the giants on Wall Street, we’ve had to get nimble by going agile. We’ve had to throw a lot of the traditional development methods out and cut our own path through the jungle. This blog will be an insight into the journey we’re taking. We’ve taken a lot of what we saw working in other shops and combined some of the best methods to form an agile environment that works for us. So we won’t call it XP, lean, or scrum. We’ve taken what we feel are the best of those worlds and apply them daily.

For the mea culpa: right now, I know what I know, and everything I write is the most intelligent way I know of doing something. If I knew of a better way to do something, I would be doing it that way. Seems kind of like a no brainer, but I thought it had to be said. Hopefully, two or three years from now, I’ll look back on some of these posts and think, ‘wow, I had no idea what I was doing.’ That’s the process of learning and growing that I love so much. I hope you enjoy the ride as well.

Jan 08 0 Responses

Glossary Of Agile Terms and Definitions

  • Acceptance Criteria – Measurable terms of what must be done for a user story to be acceptable to the stakeholders.
  • Backlog – Sometimes called a Product Backlog, the Backlog is a collection of user stories and tasks the development team will work on at some point in the future. Initially, this list consists of all obvious functionality, and it is allowed to grow and change as more is learned about the software.
  • Iteration – Sometimes called a Sprint, an iteration is a fixed, specific length of time resulting in a small but complete piece of working software. Multiple iterations combined create a fully integrated product.
  • Planning Poker – Planning Poker is a consensus-based estimation technique for estimating. Using this methodology, individual user stories are presented for estimation, and after a period of discussion, each developer chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story being discussed. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. The method has been popularized by Mike Cohn in his book Agile Estimating and Planning, and studies have credited it with less optimistic and more accurate estimations than other methods (K. Molokken-Ostvold and N.C. Haugen)
  • Retrospective – A meeting where a development team looks back on the previous iteration so that they can learn from their experience and apply this learning to future projects.
  • Stakeholders – Customer representatives from the business who are actively engaged in the project. They prioritize user stories and give real-time feedback throughout iterations.
  • Story Points – A measure of magnitude of a paticular user story, and it\’s size relative to the size of other user stories. Story points enable effort to be estimated without trying to estimate how long it will take.
  • User Stories – A very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.