This blog provides feedback on an agile methodology called Scrum applied to a SAP BW project. Part 2 of the blog explains the project context & scope, the team structure, how we built the product backlog and planned the project. This blog assumes that you have a basic understanding of Scrum. If needed, please refer to part 1 of this blog at Feedback on a small-scale BW project using Scrum - Part 1.
Project context and scope
The objective of the SAP BW project was to develop a set of operational and management reports for the Accounts Receivable (A/R) department in the areas of billing, payment and dunning. The reporting is quite complex because data comes from SAP ECC but also from several operational systems where some of the customer billing is done.
Because of this complexity, the A/R department has historically developed several MS Access databases to load and harmonise the data from these various sources. For various reasons (strategic and operational), it was decided to use SAP BW instead.
More than a year ago, the business analysts group within our accounting department wrote detailed specifications for all the reports needed by the A/R department. However, the project was delayed as priorities changed. It was now time to start again but using Scrum.
The team
The team included the manager of the A/R department acting as the product owner (he's the one with the vision of the product to be developed), one ScrumMaster (myself), two BW analysts and one business analyst (part-time). It was also decided that two accountants would join the project team (part-time) before the first sprint started and would act as key users once the project went live (key users train end-users, provide first level support, etc.).
The product backlog
The first step was to build the product backlog as user stories. Stories are simple descriptions of the product features from the product owner's perspective and are generally written using the following template: As a <user role> I want <goal> so that <reason>. More information on user stories can be found at:
http://www.mountaingoatsoftware.com/topics/user-stories
http://www.mountaingoatsoftware.com/books/2-user-stories-applied-for-agile-software-development
We initially populated the product backlog by creating one story per report based on the specifications already written. For example, we created a story called individual cash customer dunning report with the following description: as an A/R accountant I want to list all the bookings that are not totally paid by the customers and whose departure date are in the past so that I can send them payment reminders.
We held several workshops with the team over a two weeks period to review and get an understanding of the various stories. We also identified all the interfaces needed to bring external data into SAP BW and created one story for each of those.
Stories are written on index card or post-it. However, we quickly found that we couldn't remember, from one workshop to another, what was exactly behind each story (at the beginning, you really need to view the existing report or a mock-up to remember). Therefore, we decided to move the product backlog in electronic format (a simple Excel spreadsheet) and added hyperlinks toward existing reports or mock-ups (usually Excel files). We also added notes and comments captured during the workshops. In this way, we could quickly open the existing report and remember what was on it, review notes, etc.
What "done" means
Before estimating & planning, the team must define what "done" means. For instance, we decided that a story was done (completed) when the following conditions were met:
- Unit tests completed
- Development moved to QA
- Test data loaded in QA (needed for acceptance test)
- Acceptance test completed
- Technical documentation updated (if relevant for the story)
We did the same for sprint and release. For example, we decided that our architecture document should be up-to-date at the end of each sprint.
Defining the meaning of "done" is important for two reasons. First of all, you make sure that everything is transparent i.e. everybody knows what you mean when you say a story is done. You also ensure that you won't forget anything when estimating the size of each story. For example, loading test data in the QA environment could be time-consuming for the team.
Estimating
Once the product backlog is ready and stories are sorted by priority (i.e. the most important stories come first in the product backlog) you can estimate the size of each story in points i.e. the effort it takes to complete the story. This is done through a session of planning poker. See http://www.mountaingoatsoftware.com/topics/planning-poker.
Basically, we chose an average story and gave it 5 points. That was our reference. We then handled each story in turn starting at the top of the product backlog. For each story, we took up to 2 minutes to discuss it (I bought a very simple and inexpensive cooking timer from my local supermarket to keep things under control or at least try to, because this was not always easy!).
Each participant had a set of planning poker cards and chose the one representing his/her estimate (all cards must be revealed at the same time). If there were differences between estimates, we took another 2 minutes to discuss these differences (again, sometimes this took longer).
At this stage, the team was already doing some high-level design. For example, we had discussions about creating new InfoCube or how we would bring data from ECC or other external system. Also, don't forget about what "done" means. As said earlier, it could take time for the team to bring test data into the QA environment. This should be taken into account when estimating the size of a story.
It is very important to have the whole team in the room (including the product owner) because questions & answers flow between the participants. Most of the time, we found that we didn't need more than 2 rounds of planning poker to reach an agreement.
A word of warning: don't make each planning session too long (we made that mistake) because exhausted people don't pay attention anymore (you start loosing people after 90 minutes).
Story points versus man-days
*At the beginning of our first planning session, we had discussions about using story points versus man-days to estimate the size of our stories. Some team members, especially those with a technical background, were initially reluctant to use story points.
However, there are several good reasons for using points rather than man-days (this topicis very well covered by Mike Cohn in his book Agile Estimating and Planning). For me, the most important reason is that it is faster and easier to have an agreement between team members. For example, two developers may provide different man-days estimates for the same story (e.g. a report) because one is more familiar than the other with the tool being used (e.g. the BEx Query Designer). With points, you avoid this kind of potentially endless discussions.
I found that all the team members became comfortable with points after the first planning session.
Release planning
To build the project plan, you need to know the length of each sprint and the velocity of the team i.e. the number of story points the team can handle during one sprint.
We choose a sprint length of 3 weeks for two main reasons. First, we had some part-time team members and we thought that the fixed cost of iterating (e.g. time spent in recurring meetings) was too high compared to the time people would be available during the sprint. The second reason is that we needed to juggle around monthly financial closing (some team members wouldn't be available for several days).
We then had to determine the team velocity. This can be estimated but we decided to start the first sprint and see how many points the team would be able to deal with. We made that decision because the project was time-bound (the BW resources were only available for a few months) and the team would deliver whatever it could. This is obviously not a very satisfactory answer from a planning perspective; however, we knew more or less what we would deliver based on our experience.
Here is our initial plan with a buffer (Claude Aubry in his book Scrum recommends a 25% buffer i.e. 15% to handle additional feature / stories / bugs and 10% to reflect uncertainty in estimates):
Again, all these topics are well covered by Mike Cohn in his book Agile Estimating and Planning.
In the next blogs, I will cover our first iteration, including sprint planning, daily scrum, sprint review and retrospective and various topics like specifications by example and the impacts of Scrum on the way we handled BW development.
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:
1 Comment
