How we support Agile teams in estimates - Meetupfiles.meetup.com/1305678/Estimates_Agile_v2.pdfHow...
17
Presentation How we support Agile teams in estimates
Transcript of How we support Agile teams in estimates - Meetupfiles.meetup.com/1305678/Estimates_Agile_v2.pdfHow...
Presentation
How we support Agile teams in estimates
/
...
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
/
...
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
/
...
How did we accomplish?
Quality assurance prevention techniques,
requirements validation
requirements traceability
code coverage automated tools
code inspection
simulators
continuous integration
automated regression suite
/
...
What did we need?
The necessary steps:
To build from scratch accurate estimates
To plan the schedule
/
...
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-up/top-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:
Low/Medium/High) or consider a mix of techniques
/
...
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 50-100% 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
/
...
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
/
...
Tip: Workload Pie Chart Report
/
...
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?
/
...
Tip – check remaining Effort
/
...
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 twiki/forums/community?
/
...
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
/
...
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
/
...
In the end…we got there!
/
...
In the end…we got there!
/
...
/Thankyou!
/
[+44] 20.7193.9189
www.computaris.com
Lucia [email protected]://ro.linkedin.com/in/luciastoicescu
