Colleagues and clients are often asking what agile books they should read or have in their corporate library. Here’s a list of books I’ve read over the years that I thought would be good to start with.
The following book I believe is foundational for anyone interested in agile:
- eXtreme Programming eXplained by Kent Beck
Here are some books for those seeking to be ScrumMasters:
- Agile Project Management with Scrum by Ken Schwaber
- Agile Estimating and Planning by Mike Cohn
Here are some good books for Managers as well as ScrumMasters:
- Managing Agile Projects by Sanjiv Augustine
- Implementing Lean Software Development by Mary and Tom Poppendieck
For people wanting to read more about agile requirements:
- User Stories Applied by Mike Cohn
- Agile Software Requirements by Dean Leffingwell (not as much about requirements though, more about Scaled Agile)
For people wanting to read more about testing:
- Test-Driven Development by Example by Kent Beck
- Agile Testing by Lisa Crispin and Janet Gregory
For people wanting to read more about retrospectives:
- Project Retrospectives by Norm Kerth
- Agile Retrospectives by Esther Derby and Diana Larsen
- The Retrospective Handbook by Patrick Kua
For people wanting to read more about coaching teams:
- Coaching Agile Teams by Lyssa Adkins
For Organizational Change Management:
- Leading Change by John Kotter
Happy reading!!! And remember, don’t just “Do Agile,” “Be Agile!”
If you have other books that you feel should be added please reply below.
The intent of Planning Poker and pointing is to prevent analysis paralysis[i] and provide teams with a general, abstract, relative size for backlog items[ii] (i.e., user stories). This consensus-based activity empowers teams to collectively discuss their estimates and any assumptions that may exist that effect those estimates. Additionally, Planning Poker helps facilitate sprint planning, team capacity, and enables product owners to make decisions on which backlog items to be built.
As an agile coach I’m often asked “when should we re-point a backlog item that we’ve already pointed?”
My general guidance – don’t repoint any backlog item because it typically adds no additional value.
Are there exceptions to this? Of course there are, that’s why this is guidance and not a rule. If there is a significant change to a user story that causes it to become a different user story then I would consider repointing it.
When would this happen? What constitutes “significantly”?
- The user story stays the same but the acceptance criteria dramatically changes (it’s important to note that I’m not discussing just a refinement to the acceptance criteria). This change to the acceptance criteria in effect makes backlog items intent completely different.
- The customer realizes they had the backlog item incorrect, “I wanted user story ‘X’, but that user story was incorrect, I need to re-write the user story”.
Teams often want to re-point because they want to get “credit” for the additional work. But Planning Poker and pointing was not to establish credit. So resist the temptation to re-point and ask yourself “is re-pointing a backlog item worth it or should we be spending the time delivering working functioning code?”
Remember, don’t just “Do Agile,” “Be Agile!”
[i] Grenning, James, “Planning Poker or How to avoid analysis paralysis while release planning”, 2002.