Detailed guidelines for managing Projects using the Scrum methodology is given below.
Selection Criteria
- Client wants to use Scrum
- The project is large (many calendar months and / or man months)
- Requirements cannot be 'signed off' upfront, and / or there would be significant changes down the line
- Customer wants the freedom to refine the requirements as they go
- Customer would like to have quick business value in the form of incremental and modular releases instead of a big bang approach
Scrum Methodology
Our Scrum approach has three phases
- Planning:
Definition of a new release based on currently known backlog
- Scrum master compiles a Project backlog with the list of all current tasks and issues. Product owner (typically the sponsor or customer) priorities them in order of business value.
- Team members pick tasks and estimate time needed for their respective tasks. They then break the tasks into small 1-2 day tasks for easier tracking and unit testing.
- A sprint is typically 4 weeks for large projects, but may be reduced from case to case.
- The team plans only for the next sprint.
- There is a quality plan which defines the quality steps for each task . The task must be struck off the list only when it has passed all the items in the Quality plan.
- Development:
Development of the new release functionality, with constant respect to the variables of time, requirements, quality, and Business value to customer.
Interaction with these variables defines the end of development cycles.
- The team members work on their respective tasks.
- The Scrum master holds a daily 15 to 30 minute Scrum meeting where he monitors each team members progress . If it is going off target he tries to find out why and tries to help the member either with help on the spot or some off line action. Each member has to break his task into daily milestones for easy tracking.
- However, the member will try to make deliveries every 2 to 3 days so that the QA team can unit test them. QA will do OOPS class based testing and not just form testing.
- If a member is slack he will be mentored by the Scrum master . If a member is underestimating or overestimating the Scrum master will guide the member is better estimation.
- Closure:
Preparation for release, including final documentation, pre-release staged testing, and release
- Whatever is done will be released at the end of the Sprint.
- The delivery will be atomic in the sense that it will not have semantic or syntactic inconsistencies and has immediate business value to the customer without much ado.
- There is an internal retrospective meeting where the Scrum master and team note the successes and failures of the sprint , and try to learn for the next sprint.
Conclusion
This is a living document and will be updated or changed with our continued learning and PDCA endeavors.
|
