In this sprint we have chosen stories with multiple components. People are getting anxious as they will have to now depend on other people to finish their work. There is coordination involved. For example schema design has to finish before the web application functionality or service layer can be built. If schema design task of the same story is chosen by developer A and web application functionality is chosen by developer B, developer B has to co-ordinate with developer A. Developer B cannot start before developer A finishes his work. To avoid this, developer B comes up with cool idea of splitting the story into two stories - database design and web application functionality where database design can be scheduled in this sprint and web application functionality can be built in next sprint. Developer B calls it as a Common Sense Approach.
This common sense approach does not make sense because of following reasons:
- Scrum emphasizes on self managing teams. It is very important that the team learns how to manage itself and how to collaborate with each other.
- The use cases or user stories are supposed to be written more in use case manner. They must be business oriented. The stories must not be engineering driven, but strictly business driven. The stories in sprint 1 were not written correctly. They should have been written more in business manner.
- First schema design, then serially building functionality of web application sounds more waterfally. Using agile processes schema design and building web application functionality should be doable in the same iteration.
He explained to the team that Scrum encourages to build a narrow piece of end to end functionality instead of artifacts such as schema design so that it can generate maximum business value. This also facilitates the feedback loop thereby giving product managers a chance to refine ideas on the product. People seemed to be convinced.
