Your team’s three-point story might be another team’s five-point story. Using story points as a measure of success destroys its usefulness as a means of estimation, and invites “gaming the system” to appear successful (velocity X achieved) without actually being successful (working, useful software delivered).
The fix is simple: agree on and measure useful goals with the product owner (or better yet, the users). Don't mistake comformance-to-estimate or compliance-with-plan for “success”; success is value delivered.
Comparing velocities of teams or individuals
Obsessing over metrics is almost second nature to most programmers. But if your team considers velocity, the (average) measure of story points per iteration at the team level used in sprint planning, as a point of comparison, you’re doing it wrong.
Again, velocity is a neutral metric intended only for estimation. Comparing team velocities is meaningless because the basic unit (a story point) is “defined” differently for each team. Because teams are unique, comparison of velocities has no value, and doing so can encourage negative behaviors and interteam competition instead of cooperation.
The same goes for individuals that make up a team. The individual’s contribution to the story point effort is fractional. And, as above, story points themselves are not metrics. Comparing velocities of individuals, even on the same team, is meaningless. The only metric that matters is a subjective metric: value delivered via working software.
The easiest fix for this: Stop. It's counterproductive and a waste of time.
Writing tasks instead of stories
The agile story template is useful for framing a feature in terms of its benefits for a particular user/role. This reminds us that our goal is to deliver working software to someone who expects specific benefits from using it. If most of your “stories” are tasks in disguise, then the development process becomes task-focused (doing things) instead of delivery-focused (creating value). It's important for the development team to stay connected to users; software with no users is useless.
The fix for this is balance: There will always be some tasklike items that must be done, but a story should be sized well enough to be completed in a single iteration, so breaking it into tasks serves no purpose. A 75 percent “done” story is useless. Do or do not; there is no partial credit. If a story is so complex that it cannot be done in one iteration, and it does not naturally divide into substories, play it more than once (see next section).
Never iterating stories
If you’re decomposing larger stories into smaller stories merely so they can be completed in a single sprint, you’re doing it wrong. The result of this kind of practice is a set of less-cohesive, task-oriented “stories.” Instead, stick to the larger, more natural story, and let it play in multiple sprints. Attack the story end-to-end, starting with the smallest “walking skeleton” of functionalities that enable the intended capability, then layer in additional behaviors and elements in later sprints. This allows the story to stay intact, evolving from walking skeleton to usability.
Sign up for CIO Asia eNewsletters.