Is it 3hrs? One day? Perhaps 3 days? Less than 2 weeks right? Let’s discuss…
Dominik Raniszewski hosted a fascinating and collaborative Open Space workshop at Readify Sydney recently. The theme was “Agile” software development.
Open Space is a daring and marvelous exploration of the vast and urgent need for personal and organizational transformation. An excellent way to gather and highlight shared concerns and without any of the faff around preparation or performance.
We started the evening by writing up questions we wanted to address. These ideas were then organised into 9 forums. We resolved various areas on topics like like “team size”, “getting things done – done”, “communicating better”, “sharing knowledge faster”, “agreeing on process”, “delivery”, and many other interesting concepts.
One questions got me thinking…
Is there an optimal PBI size?
“It depends on what you mean by ‘PBI’ and ‘complete’, right?”
Let’s back up a little. Firstly. What is a PBI?
A Product Backlog Item (PBI) is a SCRUM term that defines is a single feature or story. A PBI delivers a single piece of real business value to customers, to production. Typically it involves some planning, some “doing stuff” and then some “checking stuff is done”.
For the purposes of finding an optimal length we decided that a PBI involved the following work:
- Write some code that matches given acceptance criteria.
- Test it.
- Deploy it to production.
To start the conversation we broke it down into two types of PBI’s. Big ones. Small ones.
- Difficult to test. Never ending and often include far too much acceptance criteria.
- Um. Easy to test. Well contained to a single vertical business value proposition that delivers easy to understand and approve functionality.
- Lack of visibility. A rabbit hole of changing requirements and unexpected additional work.
- Complexity. The bigger it gets the more complex it can be. Often our challenge is to find a way to simplify complex problem by breaking them down. Hammer time.
“Big problem = Complex problem?”
- Flow. It’s so nice to work on something and within a day have something to show for it. Small stuff feels progressive. Developer flow is important.
- Visibility. Being able to report on work that is “complete” fast helps illustrate how we are trekking with more detail. It helps managers pivot.
- Overhead and churn. Each story comes with a significant overhead. Process, release management and planning. Breaking things down into small items can often duplicate this work.
- Easier to understand. Stuff that can be explained within a few minutes is usually easier to understand and easier to sign off.
- Easier for an individual to “own”.
So, what’s the optimal PBI size?
After some discussion we came to the conclusion that there is no optimal PBI size. It’s a team decision.
Finding the optimal PBI size is something that comes with time. A team will arrive at the right size for them if they are given the opportunity to stick together and mature collectively. A team that has developed through Tuckman’s various social Forming, Storming, Norming and Performing stages will be able to find an optimal task size for any given task. This is our goal.
Thank you Dominik. I learnt a lot. I look forward to your next session!