I am currently over seeing a project that has been broken down into a number of stages of development – the current stage has required us to adopt an agile methodology and we have created a number of defined sprints. It is always a delicate process when trying to review the requirements of the business and identify the best way to meet them with the available resources.
Sprints can vary in length but are generally anywhere from a week to a month. The length should be determined in consultation with the client (product owner – the client voice). In addition, the items to be included in the sprint should be defined with the product owner. In this current project we have decided to go with sprints a week in length followed by a week of testing. The second sprint will be running concurrently with the testing week of the first sprint and so forth.
In addition to this, the customer is also running sprints for their team for tasks that do have some dependencies on the tasks my team are completing and vice-versa. In this instance we have attempted to have synchronised sprints where the sprints for both teams start on the same day, however our sprint runs for a week (5 working days) while the customer has a sprint length of 7working days. The work of both teams meets within the testing week and in our test environment. Once the testing week is complete the solution for the particular sprint is pushed to the customer’s test environment.
I am particularly eager to observe and reflect how these overlapping sprints will pan out and what impact it will have on my team, the client and the product. One point I am keenly aware of is the need to sharply monitor the functional requirements delivered by the customer, as requirements have a way of sneaking up on you and before you know it you have scope creep and run the risk of not completing the set sprint tasks.
Over the next few weeks I will continue to observe the process and write my thoughts and reflections.