Teams started to work in Agile Scrum in OCT 2010
Working in Scrum for more than 7 months</li></li></ul><li>Getting complexity points accurate<br /><ul><li> Complexity points are key to successful velocity calculation
Inaccurate velocity will prevent to execute effectively and in most cases will result in failed sprint</li></ul>Lessons learned <br /><ul><li> Getting very clear baseline (eg. what is complexity for 3 points)
Discuss until it’s understood by every team member
Refer to baseline estimations as much as possible. </li></li></ul><li>Urgent/unplanned requests from Operators or OEMs <br /><ul><li> We must remain flexible & respond quickly to critical operator/OEM requests – even if outside of Sprint commitment. </li></ul>Lessons learned <br /><ul><li> Mandatory content – features/bug fixes that are mandatory for successful sprint. Typically ~ 60% of velocity.
If unplanned request comes in, part or all optional content is replaced by new requests.
If no unplanned request – team delivers both – mandatory and optional content. </li></li></ul><li>Getting burn down chart to work<br /><ul><li>Burndown - visibility of sprint progress</li></ul>Lessons learned. <br /><ul><li> Break down as much as possible
Daily manual verification of changes</li></li></ul><li>Definition of done – when to close sprint task<br /><ul><li> “Done” – state when sprint task can be closed (when it reflects on brundown chart)</li></ul>Lessons learned. <br /><ul><li> Done may vary between teams
Discuss, define & communicate definition of done as clear as possible until fully understood by team.
In Android, BlackBerry, Java ME task is done when: