Scrum and XP from the Trenches by Henrik Kniberg

Rating: Very interesting.

I've read this one initially at the end of 2006. Lots of interesting,
real-life observations.

Scrum Concepts:

• velocity (aka actual velocity) - the sum of all initial estimates of story points, for stories completed in one sprint,
• estimated velocity -  the sum of all initial estimates of story points, for all stories planned for one sprint,
• external vs internal quality (visible to the user or not)
• yesterday's weather - look back several sprints and average out the estimates
• taskboard - index cards for stories, and post-it notes for tasks on a wall, grouped into: not checked out (stories and tasks), checked out (tasks), done (stories and tasks), unplanned items, next (stories), aka: sprint goal, burndown chart
• seat the team together for audibility, visibility, isolation:  
• audibility - any team member should be able to talk to any other team member without shouting or leaving his/her desk
• visibility - any team member should be able to see any other team member and the taskboard without leaving his/her desk
• isolation - the team does not disturb anyone else, and nobody disturbs the team
• "knowledge bridge" person - a person attending all retrospectives
• insert a lab day between sprints - page 74
• acceptance thresholds - for release planning and fixed price contracts
• all-hands pulse meeting - weekly, 15 minutes, the teams share information about what they are doing
• the firefighting team - a temporary team that protects scrum teams from interruptions by fixing bugs, or finishing old business

Code Branching Tips:
 * trunk should always build
 * tag each release
 * when in doubt, do not branch
 * synchronize often

XP Concepts:
 * pair programming
 * test-driven development
 * incremental design
 * continuous integration
 * collective code ownership
 * informative workspace
 * coding standard
 * sustainable pace / energized work


Interesting observations:

• for keeping product backlog, the product owners preferred shared Excel file to a bug tracking system, because the Excel file required fewer clicks
• internal quality should not be negotiable
• 3 week sprints worked best
• a meaningful sprint goal is important to keep the team focused
• sprint backlog is initially defined as a list of stories from product backlog, not tasks; later in chapter 6, the associated tasks are shown on the taskboard
• product backlog has the following pieces of information: ID, name, importance, initial estimate, how to demo, and notes - all are printed on cards for the planning meeting
• tasks estimated in story points (ideal days), down to 0.5
• demo of a technical story does not have to be a demo on a computer, it can be a piece of paper showing test results - page 66
• code review is an OK alternative to pair programming
• most teams do not include acceptance testing in the sprint, because it cannot be time-boxed

Quotes:

"TDD is hard, but trying to do TDD on a code base that wasn't built using TDD from start... that's really hard! [...] Lesson learned: If you are stuck with having to do manual regression testing, and want to automate this away, don't (unless it is really easy). Instead, build stuff that makes manual regression testing easier. Then consider automating the actual testing."

Tools/frameworks mentioned in context of TDD:
jUnit, httpUnit, TestNG, Selenium, HSQLDB, Cobertura, Spring