Creating a test sprint or varying the length of a sprint might seem like helpful ideas to address common problems on agile projects, but they should be avoided at all costs. These anti-patterns won’t fix the real underlying issues; in fact, they will probably exacerbate them and weaken your team.
Why tear down a liveable house when you could remodel it to suit your specific needs? Specializing in test-driven development, “chief code whisperer” Scott Ford has built a team at Corgibytes to fix and maintain existing applications, which he likens to solving a mystery. Here, he advocates for disciplined documentation and offers suggestions for project managers who want to "peek" into the process. [13:45]
Velocity is an agile planning tool, not a measure of productivity. Its purpose is to help determine which stories will fit into a sprint, and how many sprints remain until a release is ready or the project is done. Velocity is not about team efficiency or effectiveness, and treating it as a metric to continually improve is another Agile Anti-Pattern.
It can seem like a good idea to add a backup story into a sprint — if works gets blocked or things turn out easier than expected, another story can be pulled into the sprint. However, having more than one story identified, even if not committed, is likely to lead to less work getting done.
Given their fundamental differences, can Agile and Waterfall methodologies really be combined without causing more headaches than the effort is worth? Yes, but like any successful marriage, it takes some compromise and adjustment. Here are a few guidelines to make it work and reap the best of both worlds.
Writing effective user stories on Agile projects requires collaboration between the product owner and team. The effort involves agreeing on the depth of technical detail in the story, ensuring that epics are appropriately broken down, and adding acceptance criteria. Let’s look at some helpful examples for each step.
There are many ways that story points are often used incorrectly by well-meaning teams. In the fourth installment of our series, we look at two more agile anti-patterns that seem like good ideas but aren’t: allowing everyone to have a vote, and playing “Go Fish” during planning exercises.
In agile projects, most requirements start out as epics, which are too big to be addressed in a single sprint. Let’s look at some examples of how epics are broken down into manageable stories through team and user collaboration, and how acceptance criteria add important details.
CA Technologies and VersionOne have partnered on a solution that integrates Agile and waterfall project management, providing visibility across all development initiatives and enabling improved business-level decision making.
Requirements in Agile environments are handled very differently than in projects following linear processes. In Scrum, requirements are collected and shared through user stories, which have a precise format that invites conversation and collaboration. Here are some examples and guidelines for writing effective user stories.