Tagplanning

Tracking progress of the release

T

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

S

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. It’s a common problem for many teams...

Inter-team Commitment Stories

I

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. In traditional projects, it’s a PM’s task to ensure that all the team members are working on right tasks in right order. She is the one who decides about priorities...

Estimating software projects

E

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 and...

100% utilisation myth and slack time

1

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

R

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...