Agile (Scrum Approach) for Documentation

Software development is guided by the increasing customer needs, and the challenge is to deliver usable software continuously. To address this Agile Methodology was developed.

Agile methods deal with unpredictability by depending on people and their creativity rather than formalized processes (Cockburn, 2002). Agile methods are characterized by short, iterative cycles of development driven by product features, collaborative decision making, incorporation of rapid feedback, and continuous integration of changes into the system under development (Highsmith, 2002). Thus, agile methods operate on the principle of “just enough method” because they avoid cumbersome and time-consuming processes that add little value to the software product development process.

In this article, I will focus on SCRUM approach for documentation that work with the development and deliver effective documentation for the product releases.

Scrum is an approach that offers flexibility, adaptability, and productivity to the software development and does not define any development techniques. However, scrum focuses on how the team members function in a constantly changing environment.

Scrum Process includes three phases: pre-game, development, and post-game.

Pre-game Phase includes Planning and Architecture cycle. During the planning cycle a detailed plan on various sprints, duration of each sprint is estimated. A Backlog list is produced containing all requirements that are currently known and they are prioritized (a sprint), the effort needed for its implementation is assessed, and the workflow (stages) of the doc cycle is defined. In the architecture cycle, the backlog items assigned are reviewed, changes necessary to implement the backlog items is identified, a high level design (topics and structure) of various doc deliverables for all the backlog items is produced, problems or issues in developing the content is identified, and finally reassign changes as required.

Development Phase is an iterative cycle. Here the Scrum team establishes the parameters such as time, quality, resources, tools, the Output format. The parameters may change during the process and they are observed and controlled during sprint review meetings of the development phase.

Post-Game Phase is an end of release cycle where all requirements are met and completed. In this phase the tasks such as unit testing, integration, and publishing is accomplished.

The Process We followed the monthly sprint, the sprint is started with sprint planning meeting and ends with sprint review meeting. However, we also had daily review meetings (Sun Rise Meeting) in the morning to review and control the variables.

During the sun rise meeting, the information is updated in a simple sprint backlog template in the wiki; burndown chart and cumulative flow diagrams are displayed in the wiki page for everyone to view the doc status. In this course the doc team knows where they stand and it makes them feel accountable for the successful delivery of the docs for the product. This also brings in transparency to the doc status so that other teams, such as Dev, QE, Product Management, and Project Scrum Manager feel comfortable. Since, we implemented the team has had remarkable success and increased efficiency. It has helped the team to present an objective data for the end of cycle sprint meetings, and it has helped in effective estimation for the new features that needs to be documented.

Using Sprint Backlog Sheet

At the planning stage of each sprint, we create a Sprint Backlog Sheet that contains 8 worksheets: CFD, Burndown, Instructions, Backlog, Stats, Sprint Goals, Allocation, and Impediments.

CFD Sheet: is a stacked area chart that displays what state each topic is in over time. It shows how many topics are in each stage for each day of the sprint. The sprint goal is to move all work items to the final stage (Release to Testing).

Burndown Sheet: contains visuals on

• Sprint progress - how is the team doing toward meeting the Sprint goal?
• Release progress - will the release be on time with the quality and all functionalities documented?
• Product progress - how is the doc deliverables filling out compared to what's needed?

Backlog Sheet: contains all of the topics that we agree to complete during the sprint. It also contains the following details: the backlog Item number, date created, the current sprint number unless carried over from prior sprint; can be blank, status, codes, activity type, initial estimate of hours to complete task, resource - team member(s) who signed up during planning session, and daily burndown updates.

Stats Sheet: contains the source data that generates the CFD. Every day we input the counts of work items in each state.

Sprint Goals Sheet: contains the sprint objective(s)

Allocation Sheet: contains work through allocation vs. capacity data

Impediments Sheet: contains impediments for the sprint on a daily basis

Daily Scrum Meeting
We have daily sunrise meeting in same place & time each day (15 minute max):
The following points are discussed:

• What a team member is accomplished since the last Scrum?
• What will h/she work on between now and the next Scrum?
• What impediments or obstacles do h/she need help with?
  

Some of the rules we set for the sunrise meeting are

• Punctuality is mandatory - we introduced punishments, some of the penalty ideas are donating Rs. 100 to team's favorite charity, Must tell a joke at the end of the Scrum, Must sing a song at the end of the Scrum
• Attendance at each Scrum is mandatory; few exceptions are allowed
• If a member will miss a Scrum, h/she must let the Scrum Master know
• Written status to Scrum Master
• Scrum Master reads status

For sample sheet contact me: upendranb@gmail.com