Having a good Definition of Done (DoD) might be one of the most important technical asset of a Scrum team. This makes the difference between delivering at the end of the sprint fully completed business features or half-baked software. In his blog post “Changing the Definition of Done”, Ken Rubin discusses the situation where a Scrum team might want to change an existing Definition of Done.
In an ideal Agile world, the Scrum team can complete all user stories tasks that it planned for the current sprint. The real world is however different. In this article, Scott Lively explains how to use the sprint data to modify the team behavior.
In regulated industries like Health Care you have to comply with standard operating procedures, heaps of paper work and frequent audits. Do these requirements conflict with the core tenets of Agile? How do you increase velocity in such regulated environments?
As there is no all-size fits all software development process, even Scrum practitioners can learn some tricks from Rational Unified Process (RUP) for implementing more effective the customer’s requirements. The iterations from RUP can help stabilize the agile approach and offer increasing predictability of the developed software, future architecture and spent budget while keeping the flexibility toward client’s requests, development team buy-in and involvement, and the incremental delivery of the developed system.
In a Scrum context, the definition of a “spike” is “a story or task aimed at answering a question or gathering information, rather than at producing shippable product.” In this article, Bill Ambrosini discusses how to manage them and when to use this activity.
Sprint lengths should be chosen in relation to project duration; however, they should never be longer than four weeks. Consider a three-month project. If it has four-week sprints, the stakeholders will only get to participate in two demos before the project is released. This is not enough feedback to mitigate the risks. Shorter sprint lengths are a necessity.
Whether you follow a Agile framework like Scrum with its planning poker or a traditional project management approach, the estimation activity is always difficult to perform productively and consistently on the long term.