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

Estimating your Technical Writing Project

I was engaged in a pre-sales activity and one of the clients gave me few functional specs and requirement docs and asked me to come up with an estimate for an user guide.

That is when I began to look at different tools and methods used in estimating, and I explored the following options to provided estimates:
· Based on SWAG (scientific wild-ass guess)
· Based on previous (historical) data for similar kind of project
· Based on industry standard

SWAGing it Out
I went into a huddle with my team and asked them to take a guess and come up with an effort time for the project. Every one had different values; Team Member A gave 200 hrs, Team Member B gave 250 hrs, and Team Member C gave 215 hrs, and so on. I was in a fix, whom to consider? Each team member's expertise varied, one was good in information gathering, and the other in outlining the framework, and so on.

I took the approach of looking back at what we have accomplished (historic data), and come up with the number for the current set of requirements.

History shows that we made it; if we pursue, we can do it this time too

The challenge was to dig deep and pull out the numbers (effort time) from the documentation project we had undertaken earlier. When I began to do this, I found that for few of the projects I could get some values and for most I could not, because no effort was made in capturing the effort time for the entire life cycle.

Back to Square One, confidence on the estimate was low. Looking at the industry standard was the other option that was left with me to come up with an estimate.

How others estimate? What is the Ball Park? Can we apply it?

I assumed if I start googling out, I could come up with the numbers used by the industry for estimating. When I did that, I had the following questions:

· How many pages, one can produce in a day?
· How scope changes was handled?
· How complex was the project?
· How many new topics and updates were accomplished?
· What was the strength and experience level of the team members?
And so on.

The numbers for each scenario (complexity, audience, domain, skill, and so on) were different; however, I arrived at project estimates sans confidence or comfort.

There is no way to come up with an accurate estimate, estimates are just guesstimates. This thought was ethched in my brains, but I had to overcome this to be effective. Hence, I worked on a formula to increase my confidence over the estimates arrived based on standards used in an e-learning project estimation, and the formula is:

A (Estimates) = xx hrs
B (Project Loss Time) = 15% of A
C (Sub Total 1) = A + B
D (Labor Contingency) = 20% of C
E (Non Project Loss) = 15% of C
F ( Grand Estimate) = C+D+E

For example,
Estimates = 200 hrs
Project Loss Time = 200*15% = 30hrs
Sub Total 1 = 230 hrs
Labor Contingency = 230* 20% = 46hrs
Non Project Loss = 230*15% = 34.5 hrs
Grand Estimate = 230 + 46 + 34.5 = 310.5 hrs

I was satisfied with the result, and we submitted our estimates and were awarded the project. The estimates we made were almost correct (85% confidence), a great number to achieve. However, it did not stop me from exploring better ways to estimate effectively.

That is when I was introduced to Three-Point estimation technique. This technique gave me confidence in building an estimation process that has worked 95% of the time (for me).

The Three Point Estimation Technique is based on statistical methods (Normal distribution).
In Three Point Estimation, three values are calculated for every estimate:
a = the best case estimate (optimistic)
m = the most likely estimate
b = the worst case estimate (pessimistic)

These values are used to calculate weighted average (E value) for the estimate and a Standard Deviation (SD) where:
E = a + (4*m) + b / 6
SD = (b - a)/6

E is accounted both in the optimistic and pessimistic estimate, and SD measures the variability or uncertainty in the estimate.

To produce a project estimate:

· Decompose the project into a list of estimable tasks (Work Breakdown Structure)
· Estimate the E value and SD for each task
· Calculate the E value for the total project work as E (Project Work) = Σ E (Task)
· Calculate the SD value for the total project work as SD (Project Work) = √Σ SD (Task) 2

Then use the E and SD values to convert the project estimates to Confidence Levels as follows:
Confidence Level in E value is approximately 50%
Confidence Level in E value + SD is approximately 70%
Confidence Level in E value + 2 * SD is approximately 95%
Confidence Level in E value + 3 * SD is approximately 99.5%


Here is a tool developed based on Three-Point Estimation Technique for our documentation projects and it is based on ideas (templated designed) by Margie Yundt & Sherry McMenemy, Jim Chapman, and PMBOK . Although this tool is still a work-in-progress, I am happy to share what I’ve got so far.



For more on the tool, see my article on Three-Point Estimation Tool for Documentation.