Design Sprints have changed the way businesses create new products and services. But how do they relate to Agile development sprints? And how can the two be connected so that Scrum teams deliver higher quality products in less time?
The Scrum Glossary defines the Sprint Goal as “a short expression of the purpose of a Sprint, often a business problem that is addressed”. In this article Özmen Adibelli provides a facilitation meeting structure and some tips on how to facilitate a session about a controversial topic like the Sprint Goal.
The Google design sprint framework is a five-phase framework developed by Google that helps answer critical business questions through rapid prototyping and user testing. The design sprints let teams reach clearly defined goals and deliverables and gain key learnings. According to Google, this process helps spark innovation, encourage user-centered thinking, align teams under a shared vision, and get faster to product launch.
In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don’t have a “done” status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items.
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?