How we support Agile teams in estimates. Presentation

Transcription

1 How we support Agile teams in estimates Presentation

2 The Context for Agile in Computaris projects Customer and business context Rapid changes in telecom infrastructure: changes of technologies combined with an increased variety of network elements Managing growing deployments Complex systems that require an adaptive change management system Integrating customer feedback early through demos and presentations, transparently and adapting to changing requirements

3 What did we accomplish? > Successful delivery of complex products (1500+ MDs and 9+ people teams) through Agile methodologies, specifically where GUI is involved > Meeting aggressive timelines, while producing higher-quality software more productively

4 How did we accomplish? Quality assurance prevention techniques, requirements validation requirements traceability code coverage automated tools code inspection simulators continuous integration automated regression suite

5 What did we need? The necessary steps: To build from scratch accurate estimates To plan the schedule

6 Facts >It s not easy to estimate something that is being built for the first time. >We rarely built the same feature twice, so we had to use comparisons to potentially similar features or use expert judgement. >Estimating is an ongoing process, and we estimated closer to reality as we got to the project end >The velocity variated up to 25% >The classical Bottom-uptop-down estimation estimating techniques did not work > Estimating is a continuous learning effort for the team. Same is documenting them >Sometimes it was easier to estimate relative size (T-shirts, complexity: LowMediumHigh) or consider a mix of techniques

7 Lessons Learned > Setup effort is smaller if one senior developer builds a project structure and then bring the whole team on board > Trainings for new technologies had be accounted for % of Sprint 0 time, and at least 25% for the next 3 Sprints > Rework should be planned in case we use new technologies > We learned to plan for maintaining regression tests in each sprint or once in 2-3 Sprints

8 Lessons Learned > Each sprint we learned to account for bug fixing and re-testing bug fixes for at least 10-15% of dev time > It proved easier to have QA start 1 Sprint behind Dev > Thanks to our innovation program we never stop work : ) > Spend time in estimating in advance only for items that the PO targets for the next 1 or 2 Sprints

9 Tip: Workload Pie Chart Report

10 How we refined our estimates Questions when doing estimates: >Have we done this before in our team? >Have we done this before in the company? >Is there anything free we can reuse? >In how many ways can we do it? >What is the best way to do it? Why? >Can we study this and regroup tomorrow morning for Sprint Planning? >At Sprint Planning, ask the Product Owner: any chance what we ll be working on in next Sprint?

11 Tip check remaining Effort

12 How we refined our estimates Questions upon tasks completion: > Did you log the actual effort? How accurate? > What could you have automated? > How would you do it differently? > If you knew what you know now, how long would it take you? What about other colleagues? > Did we document what we did? > Did we contribute to internal twikiforumscommunity?

13 Tips and tricks Understanding and managing risk attitude when making estimates Consider level of experience of the persons making the estimates, especially when these are different than the ones executing the tasks Once there is a new technology that people get in love with it, it is hard to stop them from work

14 In the end we got there! We ve built a solution which can > ensure consistent quality and continuity of processes by validating human manual operations > save time with operation and maintenance flows > fill in the gap between network planning and engineering departments > prevent downtimes due to misconfiguration settings > make better business decisions

15 In the end we got there!

16 In the end we got there!

17 Thank you! Lucia Stoicescu [+44]