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.
A sprint goal is defined as the desired outcome of an iteration. The sprint goal provides a shared objective and represents the reason for undertaking the sprint. In this blog post, Roman Pichler explains what sprint goals are, why they matter, how to write and to track them.
In this article, Faisal Mahmood discusses seven reasons why a Scrum team cannot get to done at the end of a sprint. In Scrum, “done” is often defined as producing a potentially shippable product.
In his article “Creating an ATDD Ready Sprint Backlog in Scrum“, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.