The first conversation for the 6th Practical Agile meeting considered Agile, Long Term Planning and Deadlines.
One common problem when planning seems to be that the deadline is often set from on high before a clear set of requirements are available.
There was a feeling that that is a spill over from the Waterfall world where a set specification has a set end date (which, it was mentioned, was often missed).
The group felt that TShirt Sizing of a project (S, M, XL) was helpful in giving a finger in the air idea of how long it was felt a project would last but until the Project can be broken down into individual stories would a more realistic estimate of the time required be possible.
Once a backlog is in place prioritised and roughly estimated, if a team has an existing velocity, we are in a much better position to estimate (and by Estimate we mean Forecast rather than “Fixed Price Estimate“) what work is likely to be complete by any point in time. However a warning story came out that Estimates have been taken as Definite Dates to the point Marketing and Sales Teams started to use an Estimate as the basis for the selling the product!
There is a need to trust the teams to be honest as to what they feel the effort is (based on what they understand about a story at that time) and so using the velocity they can forecast what is likely to be completed by a given date. However this can only be a Snapshot. As the Backlog is continuously refined and potentially new features added to the project, the customer needs to be aware that what will be delivered will change. A Product Owner cannot expect to add a new feature into the backlog and expect no impact, and indeed it was suggested that the team need to emphasise almost one new story in by the project deadline, one story should be highlighted as dropping out for the project deadline. Which one of course would be up to the Product Owner. In any case the team, via the ScrumMaster, needs to make sure that these changes are reflected in the predicted delivery and that these revisions are communicated back to the Product Owner and stakeholders.
Story points are in key tool in any planning activity. An ideal is to have a full prioritised backlog of well constructed stories with acceptance criteria, which can then have the effort estimated using story points. We can use the established velocity of the team to forecast when stories are likely to be delivered and this can help drive the prioritisation of the backlog as the Product Owner can more easily see what value is likely to be delivered when. We can produce a burn up to illustrate a growth in effort and so highlight growth of a projects scope to the Product Owner in order to manage expectations and where necessary drive re-prioritisation and the understanding that if a new story will be worked on, other stories cannot be.
Burn Up of a Project’s Scope
One issue that must be avoided (especially where the team has no established velocity) is to create a velocity that ensures that the estimated backlog will be completed by a specific deadline ie we have 5 sprints worth of time, the backlog is estimated at 200 points, therefore the team’s velocity gets set to 40. The team must, if necessary, be trusted to honestly come up with their own estimate of velocity based on what they feel is achievable in a sprint. Any forecast can (and should) be challenged, but the final call must be the people who will be doing the work.
One common factor everyone agreed to was that it is always best to have a Single Full time Product Owner who is ideally embedded with the team. It was also felt that far too often it was the Development Team who were blamed when a Project didn’t hit the deadline.
On the other hand it was felt developers (in particular) had a tendency to over estimate (although there were examples where they would under estimate). It must be recognised the estimation is something people are bad at and though with time estimates will hopefully improve they are just a forecast and not a promise. This emphasises the need for continual refinement of the backlog and not just accepting any original estimate – with knowledge developed from experience in working on a particular project stories may require less effort (or more). Again the team needs to communicate clearly any impact of this refinement on what can be delivered.
For longer term planning Road Maps (an outline of what upcoming projects were due to be started) were considered to be very useful, not just in communicating the plan to the wider audiaence but also enabling the team(s) to start thinking about upcoming projects.
Release Planning was a very popular idea, even where it wasn’t being applied. It was felt that this would help communicate what features were to be delivered when for a project and could help with planning sales and training needs. Iterative Releases where only small changes were made was felt to be preferable to Big Bang Releases where much fuller training would be needed but there is often push back from the business who initially want to see everything released together. Feature switching was felt to be able to help find the best compromise between these two release strategies.
In summary – it felt from the discussion that Agile can provide useful forecasts as to what work is likely to have been completed by a deadline, but this must be subject to continuous review. The team can provide this forecast to enable the Product Owner (and so the business) to continuously evaluate what features will likely be available at any point and so judge the value of any further development. What Agile cannot do is make is make the time and effort needed to complete a project arbitrarily match a deadline.