Monday, May 31, 2010

Sustainable Test Driven Development

Growing Object-Oriented Software, Guided by TestsAt QCON, Steve Freeman gave a talk on Sustainable Test Driven Development. Steve show examples of bad tests and gives us advice on how to write good tests that make development easier and easy to maintain. Steve recommends the following:

1. Test Readability: Make sure the tests are readable.

2. Test features and not implementation: Do not write a test for each method in a class, but instead write test for specific features and behaviors.

3. Use helper messages to remove noise and be more expressive.

4. Use self describing variables.

5. Use test data builders that fill in defaults for values not specified.

6. Test the what not the how.

7. Always add message in the assert to explain the test.

8. Overload toString to get descriptive error messages.

9. Specify precisely what should happen and no more.

10. Avoid brittle tests like hardcoding values. For example, when trying to assert for auto-incremental id values, simply test that the value got incremented instead of asserting against an actual value.

Test Driven Development: By Example11. Only enforce order of methods when it matters.
Steve concludes that tests are code too. They need all the same care and attention given to code. Tests need to focus on what matters. We should value expressiveness over convenience and make sure the tests are readable. If a class is hard to test then it’s a clue that our code is too complex.

This presentation is available on InfoQ at

Tuesday, May 25, 2010

You Say Tomato, I Say Pomodoro

The Pomodoro TechniqueThe Pomodoro technique (Italian for tomato) is a time management technique created by Francesco Cirillo. The technique uses a timer to break down periods of work into 25 minute intervals separated by breaks. It is based on the idea that frequent breaks can improve mental agility.
The technique uses a form of timeboxing and relates well to Scrum and other agile methods. The process is as follows:
Pomodoro Technique Illustrated: Can You Focus - Really Focus - for 25 Minutes? (Pragmatic Life)
1.    Choose a task to be accomplished
2.    Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3.    Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4.    Take a short break (5 minutes is OK)
5.    Every 4 Pomodoros take a longer break

Tuesday, May 18, 2010

Splitting Stories

Agile Estimating and PlanningMike Cohn provides guidelines on splitting stories in his books Agile Estimating and Planning as well as User Stories Applied. Stories need to be split as they rise to the top of the product backlog and near implementation. Some reasons for splitting a story are:

1. Size – Too big
    • a. Cannot give an accurate estimate: A story needs to be more manageable and enable a more accurate estimate.
    • b. Cannot fit into an iteration: If for example an iteration is 1 week long and the story in longer than a week then it needs to be split to fit into the iteration.
    • c. Cannot fit into what’s remaining of an iteration: A team has already committed to 38 story points and there is still room for a 2 point story but the remaining stories are 3 story points or more.
  • 2. Dependency: A story is dependent on another story. This makes it hard to give a correct estimate. The story needs to be split where one story handles the dependency and the others handle the specifics.
  • 3. Risk: A story is complex and risky. The story needs to be split to create a spike story which is experimental in nature and its main goal is to gain technical knowledge.
  • 4. Compound: A story contains multiple sub stories that are large enough to stand out on their own.
Succeeding with Agile: Software Development Using ScrumSome of the techniques for splitting stories include:
  • 1. Along data boundaries: For example, separate local requirements from international requirement, or handling one type of credit card from another.
  • 2. Operational boundaries: This typically is done along CRUD boundaries where for example a story is split into 3; one to create an entity, one to retrieve and update an entity, and one to delete an entity. Another example might be separating a story into search which simply return search result count and then search display which displays the actual results of a search.
  • 3. Cross Cutting Concern: Features that effect multiple aspects of the application like security, logging, error handling can each be separated out of main functionality features. For example, a screen that will have different menu options or links based on the login user’s credentials. This security specific feature can be split from the main functionality of the screen.
  • 4. Performance constraints: Functional requirement from non functional requirements can be split into separate stories. For example, a feature can be enabled without caching and then another story can handle caching specifics.
  • 5. Priority: Within a story, there might be multiple priorities. For example, a login story might have different priorities for authentication than for handling error conditions like locking out a user after multiple logins.
User Stories Applied: For Agile Software DevelopmentIt is important to not split stories into tasks like design, code front end, code middle tier, code back end. It is almost always better to deliver a cohesive subset of all layers of a feature than delivering all of one layer as a standalone. Having the entire backend ready without a corresponding GUI is not very useful, but having a feature that allows the user to add an entity through the GUI and have it persisted is functionality that can be useful and provides some value.

Finally, there might be cases where we might want to combine many small items onto one larger story. For example, bug reports can be combined into one Fix Bugs story.

Sunday, May 9, 2010

Scrum and Kanban

Kanban and Scrum - making the most of bothHenrik Kniberg and Mattias Skarin compare Scrum and Kanban in their book “Kanban and Scrum – Making the Most of Both”.

Scrum consists of
Small cross functional self-organizing teams
Time boxes for the Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective
Artifacts: Product Backlog, Sprint Backlog, Release Burndown and Spring Burndown.

Scrum requires small cross functional self-organizing teams. Each Scrum team is composed of a product owner, a ScrumMaster, and the team. The Product Owner maintains and prioritizes the product backlog in a way that maximizes value of the work performed by the team. The team works in short fixed length iterations and consists of developers with all the necessary skills to deliver the committed to features by the end of the iteration. The Sprint starts with a Sprint planning meeting to produce the Sprint backlog from high priority feature in the product backlog. This is followed with daily work on small concrete items from the Sprint backlog, and ends with a Sprint Review to demo the deliverables as well as a Sprint retrospective to review the process. Everyday the team also has a Daily Scrum meeting to ensure progress towards the Sprint goal and update the Sprint Burndown chart. A release planning meeting is held before the start of each release to estimate and prioritize features to be included in the next release. After each Sprint, the Release Burndown chart is update to show and track release progress. Throughout, the ScrumMaster ensures that the process is understood and followed and removes any impediments to the team’s progress.

Kanban is based on limits on Work in Progress. It uses a visual control mechanism (Kanban Board) to track work as it flows through the various stages of the value stream. The board tracks states like to-do, in development, in testing, completed, etc. Each state has a limit on the number of items that it can hold. Work is split into pieces and progresses through the workflow however no items can proceed unless there is enough capacity in the next state. Lead time or cycle time is constantly measured and optimized to make it as small and as predictable as possible. Kanban does not prescribe artifacts and team composition like Scrum does. Kanban leaves everything open. The only constraints are visualizing the workflow and limiting WIP.

Henrik summarizes the similarities and differences as follows:



releasable software early and often

“potentially shippable” at end of each Sprint

Scheduled or on demand

to drive process improvement

Product Backlog, Sprint Backlog, retrospectives

Kanban Board

Pull Scheduling

Items are pulled from product backlog at beginning of each Sprint

Items pulled when a slot becomes available


Timeboxed iteration prescribed for Sprint, Release
Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint

Timeboxed iterations optional. Process can
be event driven instead of timeboxed. Each meeting
can occur at different


Sprint Backlog/Scrum board is reset after each Sprint

Kanban board is persistent

Item Size

Items must be broken down to fit into 1 sprint

No sizing requirements


Estimation prescribed

Estimation optional


Prescribes a prioritized backlog

Prioritization optional


Team commits to specific work in an iteration

Commitment optional.

Process Improvement Metric

Based on Velocity

Based on Lead time


Product Backlog,
Sprint Backlog, Release Burndown and Spring Burndown prescribed

Kanban Board

WIP Limits

Indirectly based on what can
fit into a Sprint

Directly based on limits set for each stage in the workflow

Responding to change

Cannot add items to an ongoing iteration

Can add new items whenever there is capacity

Team composition

Cross-functional teams prescribed

Silos and specialist teams allowed


Sprint backlog is owned by one specific team

A Kanban board may be shared by multiple


3 roles: Product Owner, Team, ScrumMaster

No roles prescribed

Scrum and XP from the Trenches (Enterprise Software Development)Henrik and Mattias recommend you not limit yourself to one tool. Mix and match as needed based on your organization's circumstances.