MNASQ logo

December 2004 Predinner

Iterative Incremental Software Development with SCRUM By Ester Derby, December 14, 2004

Iterative Incremental Software Development with Scrum is the method of developing software from concept to delivery in 30 days. Iterative is repetition. Incremental is a small portion. Scrum is a rugby term for a team huddle, similar to the football huddle. There are many concepts that need to be incorporated into the software. The scrum team will then use iterative incremental software development to decide which feature is the most important. The team will then focus on developing working software in just 30 days on that one feature. The remaining features will be prioritized for review for the next incremental development. Each 30-day increment is called a sprint. Iterative Incremental Development is taking one requirement, analyzing, designing, building, integrating, and then testing the software all within 30 days.

The business climate is always changing. When the first increment is completed, the product may be headed in a different direction. Now the remaining concepts are reviewed, reprioritized, and a new feature is stated for development. Use ROI and the 80 / 20 rule to determine the next highest priority item to develop.

There are four keys for successful iterative incremental software development:

  1. Allow for an evolving list of software requirements by making a product backlog that contains all the requirements, technical work and future issues. Start developing more detail for the high – priority items. Create a rough estimate for each item. Then reprioritize the backlog requirement list every 30 days based on ROI, risk and customer defined priorities. But never reprioritize or change the current feature being developed.
  2. Build a piece of working software in the 30-day iteration by choosing the highest priority from the evolving list of software requirements. Focus on analysis and design for the requirement. Do not change or add to the current requirement that the scrum team is working on. Create software that has been tested, documented, and works.
  3. Develop the scrum support team to focus on building the software. The scrum management roles are the product owner, scrum master, and the scrum team.

    4. The product owner has five main responsibilities:

    • Establish and communicate the vision for the product.
    • Create and maintain the product backlog.
    • Prioritize the product backlog to maximize the ROI and solve business conflicts.
    • Assess changes in software requirements and then reprioritize the product backlog (but not the current 30-day requirement).
    • Work with senior management to make software release decisions.

    The scrum master has eight main responsibilities:

    • Manage the process by ensuring that values and practices are implemented correctly.
    • Keep non-team members from interfering with the team.
    • Protect the team from working on to many requirements at one time.
    • Remove roadblocks that delay the team.
    • Give the team empowerment that promotes creativity.
    • Assure current standards concerning documentation, engineering, etc. is followed.
    • Facilitate the daily scrum meetings.
    • Improve engineering practices and tools such as source code management, test driven development, automated builds, refactoring, coding standards, user developed acceptance test, frequent code check in, and shared code ownership.

    The scrum team has five main responsibilities:

    • Select one requirement from the product backlog for the next sprint.
    • Work with the product owner by providing cost estimates or other information that will influence the ROI or priority decisions.
    • Define the sprint requirement goal.
    • Develop the sprint requirement into working software in 30 days.
    • Participate in four scrum meetings.
    • Sprint planning meeting to look at priority backlog list to determine the next sprint.
    • Daily scrum meeting is a 15 minute, stand-up meeting to discuss the current sprint.
    • What did the team do since the last scrum meeting?
    • Are there any obstacles?
    • What needs to be done before the next meeting?
    • Sprint review meeting to discuss all stages of the current sprint.
    • Sprint retrospective meeting to discuss pass sprints in relationship to the current sprint.
  4. Keep the progress visible. Use a Burndown Chart to show remaining work on the product backlog or the current sprint. The product backlog chart can be done in months. The current sprint chart can be done in days or hours.

Customer feedback at the end of the current sprint should include a working software demonstration. The demonstration will show that progress is always being made and in the right direction. The demonstration will show that the correct requirement was built, identify any requirement misunderstandings, and generate new ideas that can be added to the backlog list. If the requirement was completed ahead of schedule, the customer may release the current software before the scheduled release date.

Not all sprints progress as planned and should be cancelled before the 30 days is complete. Cancel a sprint if the team is unable to meet the goal, external obstacles devalue the goal, or if extra work demands priority over the current sprint. Always conduct a meeting to review the reason for early cancellation to prevent a repeat cancellation.