In the dynamic realm of product development organizations, an ongoing debate between "predictable" and "agile" approaches unfolds, with perspectives often divided on the very definition of these terms.
Interrupt Buffer
In a perfect world, a Scrum team should be allowed to execute their sprint without being interrupted, and all changes or new requirements should be addressed at dedicated Scrum events. While Scrum teams should aim for a world of no sprint interruptions, it's not the reality most teams face on daily basis. Customer usually do request new functionalities, users do discover critical defects, etc...
Tracking progress of the release
Having a potentially shippable product every sprint lies in a heart of Agile, but in many organisations – especially the ones that don’t work in SaaS model – a product is not released to the market every sprint. Sometimes frequent delivery is not possible (i.e. in case some additional tasks like a translation of a documentation, legal approval, etc. have to be done at the end of the...
Splitting large features into smaller stories – Elephant Carpaccio
Many teams transitioning to Agile struggle with delivering a potentially shippable product every sprint. Producing a piece of software that provides a business value to a client every 2 weeks seems impossible. Usually, teams say that they can deliver either front-end, or backend, or architecture design for a given feature, but not all these together.
Inter-team Commitment Stories
Managing complex and lengthy projects is a challenge. When dozens of people are working on the same product in parallel there has to be a mechanism for identifying and resolving dependencies and cross-team blockers.
Estimating software projects
Couple weeks ago I came across a great article about software estimation by Pawel Brodzinski which made me think about how my approach to estimating software projects has evolved over time. At the moment I work in product development where Agile approach is used to deliver new increments of software. We have stable teams and we use Story Points and Velocity to estimate and plan our sprints...
100% utilisation myth and slack time
In my recent blog post I covered a topic of limiting Work in Progress. I briefly mentioned that in many companies working on many tasks in parallel is somehow more important than accomplishing them. 100 utilisation myth Many organisation believe that their employees should always be busy with work which results in aiming for their constant 100% utilisation. At first glance it may sound reasonable...
Relative Value Points
Product backlog should be DEEP – detailed appropriately, emergent, estimated and prioritised. Everyone who learns about Scrum should be familiar with these key attributes of a good product backlog. But how is the product backlog ordered? Well, most Scrum practitioners would probably say that it’s Product Owner’s decision, but the business value seems like a fair attribute to be...