The following tasks were practised with two scrum teams working on a variety of web and app based projects in the public sector. These teams are 2 years into their journey and followed the scrum framework and ceremonies they were collocated and ran sprint planning as two teams – which had it’s pros and cons. This document formed part of the handover when I moved on to pastures new, and was a snapshot of our understanding and the process we followed. The team released quarterly and had the remnants of a waterfall process. They had high technical excellence with continuous integration and 70% automated (unit/front-end) test coverage. Features were tested twice once in a code integrated environment without user data then every 2 months in regression with data loaded from production, which led to delays in quality feedback. An infrastructure uplift project – to make daily data integrations possible – was held up in the IT infrastructure department for 9 months (so As SM I felt partly to blame for this!). We had a large 5M line Open Source codebase with many independent features being developed simultaneously with up to 6 product owners at any one time across two teams – 9 developers per team, embeded testers however operations/infrastructure support was still in a separate department.
- Stand-Ups – 3 questions or walk the board, keep an eye on capacity (this was made visible at the stand ups on a monitor beside the boards) and work in progress and look for opportunities for collaborative work. If all items aren’t going to be completed look to guarantee the ‘Must haves’ by not starting on the Should’s and Could’s until later sprints.
- Ask stakeholders to come to the board