To get an understanding of Scrum, please refer to part 1 of this blog at Feedback on a small-scale BW project using Scrum - Part 1. To understand the project context & scope, the team structure, how the product backlog was built and the project planned, please refer to part 2 of this blog at Feedback on a small-scale BW project using Scrum - Part 2.
Our third sprint (iteration) started two weeks ago. We now have been several times through the scrum ceremonies: sprint planning, sprint review, sprint retrospective and daily scrum meetings. Part 3 of this blog provides feedback on these meetings and discusses team synchronisation and specifications by example.
Sprint planning meeting
The sprint planning meeting takes place just before starting a new sprint. The objective of the meeting is to define in details the work to be done during the sprint. This is basically done by identifying the tasks required to complete each story (if needed, some tasks that are not linked to specific stories can be added).
After reminding the whole team of the start and end date for the sprint, it is useful to review people's availability. This is important in our case because some team members are working part-time on the project and others are not available for a few days during monthly financial closing.
During the meeting, we take each story in turn and identify all the tasks needed to complete the story and estimate the effort in "ideal" hours to complete each task. Each task is written on a Post-It and placed on a wall next to the story. Our first sprint planning meeting took more than 3 hours instead of the 90 minutes planned... There were two main reasons for that:
- There was a lot of discussion about what the tasks should be and how to estimate the effort to complete them (for instance, how do you handle a task on which several people will work? Do you split it into several tasks and estimate each of those? Etc). It was a learning process and I must say that our second and especially our third sprint planning meetings went very smoothly. Typical tasks on our BW project are to write specifications by example, design, develop, move development to QA and load test data, do acceptance test, develop query, update architecture document, etc. We are actually more precise when describing tasks. For example, we explain what is being developed e.g. build the new sales InfoCube or load the client master data from the sales system.
- We didn't prepare the meeting well enough. For instance, we had too much discussion during the meeting about what stories were about. We even did some planning poker to estimate some of the stories. We now anticipate a lot more during the current sprint by having team meetings where we discussed upcoming stories and groom the product backlog (new stories may be added and estimated, priorities may have changed, etc.).
After defining and estimating the tasks for each story, I ask the team if they feel comfortable handling the next one in the coming sprint. We stop adding stories when the team says no. That's why it is important to know people's availability to be realistic about what the team can deliver. You also need to make sure that you have a buffer to handle extra work during the sprint (you need to anticipate the next sprint during the current sprint and this generates work), to cover for uncertainty in estimates (tasks), etc. There are various techniques to estimate the size of this buffer. Following Claude Aubry's recommendation, I make sure we have at least a 30% buffer.
Last but not least, you need to define a goal for the sprint. In our case, the goal of the first sprint was to harmonise cash and credit customers (not very sexy or understandable but it made sense to the team).
As usual, these topics are well covered by Mike Cohn in his book Agile Estimating and Planning and, for French speaking people, by Claude Aubry in his book Scrum (I swear I do not get any royalties from these people).
Team synchronisation
Other team(s) involved in the project may not use Scrum (for instance, we have a dedicated team in charge of ETL, EAI, etc.). It is therefore important to synchronise their work. In such cases, you may need to write specifications (as complete as possible because iterating may not be an easily accepted option), ask for a delivery date and plan accordingly. All of that needs to be anticipated.
Specifications by example
In terms of acceptance testing, we decided to write specifications by example for each story (see Bridging the communication gap by Gojko Adzic at http://www.acceptancetesting.info/the-book/). These specifications by example must be available before the development starts and act as specifications for the developer.
For a report, the specification by example includes the list of information and calculations needed on the report (e.g. customer code and name, turnover, ageing, etc.) and the expected results based on the data available in our QA environments (where the reports are developed). We found this to be quite effective because it forces end-users & business analysts to really think things through instead of building theoretical examples. This is also a very good communication tool between the team members. And last but not least, the examples (or a subset) can be used by the developer to unit test his/her work.
Daily Scrum
Every morning, the team stands up in front of the "task board" where the tasks for each story are shown. Each team member answers three questions: what did you do yesterday, what will you do today and are you encountering any obstacle. Accordingly, tasks (Post-Its) are moved around the task board and the remaining effort (in hours) to complete each task is adjusted. The meeting lasts 15 minutes. Obviously, discussion will take place between team members. The ScrumMaster must make sure that people do not start lengthy discussions (if needed, these discussions should take place after the daily scrum). I must say that I let sometimes the meeting run a bit longer to let people share information but I keep it under control.
Task board at the end of sprint 2 (most tasks are completed). The first column contains the stories (green Post-Its). The next three columns contain tasks depending on their status (To Do, In Progress, Done).
At the end of each daily scrum, the sprint burn-down chart (remaining effort in hours) is updated.
Sprint 2 burn-down chart (end of sprint)
The whole team must attend the daily scrum meeting in order to properly synchronise the work of the team. The presence of the Product Owner is crucial because he gives direction and answers questions (during and after the daily scrum if needed). Hopefully, we have a very dedicated Product Owner (I think he hasn't missed one daily scrum except a few days ago when it snowed like hell!).
Sprint review
The objective of the sprint review is to present to the world what the team has accomplished during the sprint. We remind everybody of the goal of the sprint, the stories included in the sprint (planned versus actually completed and explain any discrepancy), explain the system architecture (data flows, InfoCubes, important business rules, etc.) and demo the system (basically, we show the various reports that have been developed). We also answer questions and explain what the team plans to do in the next sprints. It takes us one hour to cover these topics.
Sprint retrospective
The objective of the sprint retrospective is to reflect and talk about what happened during the sprint in order to improve, to avoid doing the same mistakes again and to share different points of view. The meeting lasts one hour. We take roughly half an hour to review what happened during the sprint, what went well, obstacles encountered, etc. A very useful way to do this is to draw a timeline and start talking about the first story handled by the team. This will kick-start the conversation and everything will flow. Problems and solutions will surface during the conversation.
The next step is to ask everybody to jot down their ideas for improvements on Post-Its (ask for 4 or 5 ideas per person). In turn, each team member goes to the board where ideas are grouped together. After the meeting, we add the improvements into the product backlog to keep track of them.
Sprint 1 retrospective – Timeline at the top. Ideas for improvements are grouped together.
This is a very important meeting because it really gives the team the opportunity to improve on a regular basis while the project is going on. For me, this is a very good innovation brought by Scrum (we do something similar today but usually at the end of a project which is a bit late when you think about it).
Improvements can be really simple things like, during the daily scrum, writing down the name of the person in charge of a task on the associated Post-It to more important improvements like anticipating the next sprint.
In the next blog I will provide feedback on Scrum's benefits, challenges, impacts on BW developments, etc.
Afterword
Should you have any questions on Agile/Scrum/Lean, do not hesitate to contact the Agile+ community on Google+ at http://plus.google.com/u/0/104017139996657183972/posts. Your questions will be forwared to the community if needed.
- SAP Managed Tags:
4 Comments
