In all the SAFe® training it recommends that teams have their top 10 features ready as input into their first big room planning event. This would seem reasonable for small trains but as trains can vary in size from 50 people to over 150 people the question “Just how many Features are needed to support my train?” often comes up.
Having been involved in the launch of many trains, and worked with trains that have been running for many years, we now have a better idea of what makes a suitable number of Features to get started.
The vast majority of trains that we have seen here at IJI go into their first planning event with somewhere in the region of 20 to 30 features. This is normally more than enough to keep the teams happy, and if there’s some capacity left over then that’s no problem. More Features will be ready when the first batch has been completed.
The largest train that we have been involved with had an initial backlog of 42 Features, the majority of which were pulled during the planning event, but then again there were 13 teams and it was a 14 week Program Increment (PI).
Another train that we’ve been involved with now has nine Feature Teams and has averaged 46 Features a PI over their last four PIs. They are now on PI-14 and still going strong.
The problem here is that to start any form of capacity-based planning and forecasting you need to have an estimate of the expected through-put of your team and you need to be able to size the up-coming work without any reference items.
Based on our experiences with many trains, of all shapes, sizes and distribution models, we have evolved a very simple way to establish a Feature velocity for a new train:
- Calculate the sum of all the sprints that all the development teams will complete during the PI (do not count the IP sprints).
- Adjust for any capacity allocations to maintenance or other non-feature related work. This gives you an initial estimate of the train’s velocity.
- From your list of candidate Features find one that you think will take, on average, one team a Sprint to complete and call this a 1. Estimate the other Features relative to this one. If a Feature is more than a 3 then it should probably be sliced so that it will more readily flow through the system (see our previous blog on Feature slicing).
- Compare your emerging list of estimated Features against the estimated velocity and prepare a few more Features than needed (typically one for each team) just in case the planning goes well and the team collaborations enable the teams on the train to deliver more than they would have working in isolation.
An Alternative Approach
If you want to avoid any smell of points equalling time then you could use the following formula to establish a range for the expected number of Features to prepare:
- Calculate the sum of all the sprints that all the development teams will complete during the PI (do not count the IP sprints).
- Take the number from Step 1 and subtract the number of teams to establish a lower limit.
- Take the number from 1 and add the number of teams to give an upper limit.
This range fits our experiences with trains made up of Component Teams tending to the lower number and those made up of Feature Teams the higher.
Now this is a bit clunky, but it does get people into the right ballpark and sets a reasonable level of expectation for what is a completely new approach to planning and delivery. Avoiding both the problem of running out of prepared Features during the planning event and the problem of over preparing and over refining the Program Backlog.
Once the train has completed its first PI then you will have real numbers to base your estimates and forecasts on, and can forget about all this.
This is just something that has been working for us; we hope you find it useful.
More Great Topics for Agile Teams
On the Nature of Portfolios; WSJF Estimating Portfolio & WSJF
Program Level WSJF & Feature Slicing Program WSJF & Feature Slicing
All about Managing Dispersed Planning; WSJF Estimating Dispersed Planning Series
States of Epics The EPIC lifecycle