Actively seeking and reading interesting blogs related to the work that I do leads me to interesting places. This time around, I ended up purchasing a copy of Godjko Adzic & David Evan’s 50 Quick Ideas To Improve Your User Stories e-book because I was looking for ideas to implement better software development at the office. I knew there are ways we could be more effective in shipping software (we’re good, but we’re still far behind bigger companies in terms of project releases) and it looks like the lessons in this book will definitely help us improve our agility, one small step at a time.
Here are some of my favorite lessons:
- Always ask if a story improves the current business goal.
- Impact maps can help organizations (and teams involved in a project) in understanding why a story needs to be developed and released in Production or why it may only be a pet feature and doesn’t need to be considered right now.
- Measuring team velocity and creating burn-down charts only tell us how well members of a team is working with each other. It is a negative metric, like blood pressure, and is great for finding out problems, if those are what we’re looking for. It is bad for estimating how far we are from achieving a goal, because the team can be moving at good speed but going in the wrong direction.
- Instead of waiting months to finish a project (and accomplishing a goal), why not find ways of shipping to customers piece by piece by piece in much less time and get feedback? There are many ways of splitting stories.
- Stop using numeric story sizes for estimation. Use ‘too big’, ‘too small’, and ‘just right’ instead. This way, teams will be forced to make each story into something they can manage and they can go ahead in implementing them. Stories that are ‘too big’ often needs more discussion and planning, which can be started in later sprints. As for estimating how many stories can be squeezed in for next iterations, just use the running average number of stories the team was able to finish for the past few iterations.
- To determine if a project is a successful experiment, test the stories with real end-users after release. See if the expected change in behavior (goal of the story) occurs by measuring changes. If the goal is reached, great. If not, revisit the assumptions that were set for the story. Successfully providing a feature to users doesn’t mean that the business goal is achieved.
Godjko Adzic also writes about impact maps in more detail in his other book, Impact Mapping, if you’re interested.