Sustainable Test Driven Development

At 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.

11. 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 http://www.infoq.com/presentations/Sustainable-Test-Driven-Development

You Say Tomato, I Say Pomodoro

The 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:

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

Splitting Stories

Mike 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.

Some 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.

It 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.

Scrum and Kanban

Henrik 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:

	Scrum	Kanban
Delivering releasable software early and often	“potentially shippable” at end of each Sprint	Scheduled or on demand
Transparency 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
Iterations	Timeboxed iteration prescribed for Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective	Timeboxed iterations optional. Process can be event driven instead of timeboxed. Each meeting can occur at different times.
Resets	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	Estimation prescribed	Estimation optional
Prioritization	Prescribes a prioritized backlog	Prioritization optional
Commitments	Team commits to specific work in an iteration	Commitment optional.
Process Improvement Metric	Based on Velocity	Based on Lead time
Artifacts	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
Ownership	Sprint backlog is owned by one specific team	A Kanban board may be shared by multiple teams
Roles	3 roles: Product Owner, Team, ScrumMaster	No roles prescribed

Henrik and Mattias recommend you not limit yourself to one tool. Mix and match as needed based on your organization's circumstances.