In a series of blog posts (1, 2, 3), I have described how we have incrementally improved our Agile process since I joined the team.
In the last post, I highlighted how we estimate the development efforts for each task in order to be able to prioritize our various activities. We have already seen how we mitigated the difficulty of estimating huge activities, and in this blog post I would like to describe how we tackle the estimation of really complex tasks, which are difficult not just in terms of estimating them, but also of course in achieving them.
In our experience, activities in which the technical domain is not well-known by the team, or for which the outcome expected by Product Management or our customers is not very clear, may create problems for both implementation and estimation.
In dealing with such complex activities, the estimation provided by the team will be very high, and these activities might not even be completed within a single sprint. As a consequence, we may waste a significant amount of time on them without any resulting value for our customers. Moreover, Product Management might have made different prioritization choices in the first place if our estimation were more precise.
To surmount situations like this, we have started a special investigation activity called a spike (which originated with extreme programming). Our rules are the following:
The typical outcome of the spike is that the R&D team will increase its knowledge of the “critical” activity, and better understand the outcome requested by Product Management and/or the customers. As a matter of fact, one spike outcome might be that the team members discover that the activity is more complicated than originally expected. In other cases the team might be able to deliver a Minimum Viable Product (MVP) which could be releasable.
Under those circumstances, the spike result will surely bring a better understanding of the activity to the next planning poker session, and therefore Product Management can easily decide if an additional spike is needed, whether the final activity built on top of the spike can be planned at the next sprint, or whether it is better to postpone it.