15. 10. 2024
Atlassian, Service Management
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 outcome of a spike must be a working Proof Of Concept which will be used for demonstration, gathering feedback and increasing the knowledge of the team.
- A spike is planned as usual for a single sprint, but the amount of time that can be dedicated is limited (a time-boxed approach).
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.
Michele Santuari
Software Architect at Wuerth Phoenix
Hi, my name is Michele Santuari and I am a Telecommunication engineer felt in love with OpenFlow, the first attempt of centralized network management, provisioning, and monitoring. I embraced the Software Defined Networking approach to discover a passion for programming languages. Now, I am into Agile methodologies and crazy development process management.
Author
Latest posts by Michele Santuari
23. 12. 2020
Development
RPM/ISO Repository: Disk Space Optimization
05. 10. 2020
Development, NetEye
Research Activities: A Fully Distributed NetEye
31. 03. 2020
NetEye
How Do We Test NetEye?