It’s quite a long time, i haven’t shared anything over my blog. after thinking a while, i decided to share about our maintenance sprint.

since we have been (tekSymmetry) moving from traditional project management to agile project management. as usual we are struggling and learning through our faults and adjusting, adapting and correcting accordingly to accommodate agile in our family.

agile project management seems very simple in theory and easy to transform but in reality it has so many mental and understanding related conflicts which we are stucking and discovering. yes we should have followed this and that.

for those who just started and don’t like to get in argument. you just start with scrum first, & follow all prescribed processes (learn through adapting approach.)

after working on our project for last 7 months and completing more than 20 full and short (in our case, full = 2 weeks, short = 1 week) length sprints. we reached to a point where we are feeling much confident with our process adaptation. here i will demonstrate how we are managing our maintenance sprint.  definitely our way of managing sprint won’t be the best solution for every contexts.

what is maintenance sprint?

before i proceed, i should explain what is meant by maintenance sprint.

here in the picture, you could notice few greenish circles, which we call maintenance sprint. maintenance sprints are planned for supporting a release with related bug fixing. as you know most of the software releases don’t come up with 100% bug free, it comes up with lot of known and unknown issues. to protect our visitors we keep maintenance sprints to provide continuous updates and hot fixes (;)).

how are we doing the maintenance sprint ?

Usually we are doing the following tasks during a maintenance sprint -

• Product owner prioritize the issues and provides us the list
• Sprint planning meeting with client
  
• Team select implementable issues
  
• Product owner can reshuffle and prioritize issues before sprint kick starts
• After everyone agrees (team and product owner) team tags all issues (in issue tracker) with the target release version (ie. 0.12.2)
  
• Daily team stand up meeting
  
• Team provides feedback on client’s reported issues during the day time.
• Daily reporting (we call it end of the day report)

So, how are we utilizing the white board ?

well, first let me show you our white board -

Global TODOs:

During the sprint day, this portion of the board is synchronized and maintained. we usually enlist the following topics -

• Major issue
• Task which requires feedback
• Impediment
• Any events which requires our (team) attention
• Any collaboration requirement (ie. need feedback ASAP on issue #2034)
• Any issue which we need to remember. (ie. Send report, deploy before leave the office)
• When tester finds problem during testing, they write it down on the board with red pen
• Every day during stand up meeting we write down all events/tasks/todos on the board.
  

Status BOARD:

This portion of the board is similar to scrum task board, instead of putting sticky paper we use marker to write down the issue number.

when we make progress we move issue from WIP (work in progress) to WFF (waiting for feedback) or WFT (Waiting for test). later our tester moves them to DONE. actually, rather moving physical sticky paper we wipe out the previously written text and write it again on the new column.

this board is maintained through the whole day. whenever we take new task we add it on WIP and when our task is completed, we move it on Waiting for test queue.

we follow the following rules -

• per person only one WIP (work in progress) item can be selected. (taken from kanban)
• whenever we make progress it will be reflecting the board (developer wipe out from WIP and move to next status)
• tester keeps his eyes on “test” column of the board, they eagerly wait for the change on this column
• if tester finds some problem with the issue, the write it down on “global todos” portion of the board in red pen.
• developer can retake any issue (if tester reported not resolved over “global todos”)
• during stand up meeting development team can discuss which issues need to be resolved first.

Daily report:

At the end of the sprint day, we generate a report from the board and send them to every stakeholders, clients & management. we keep this report very simple we add the 3 parts in the daily reporting -

• what we have resolved
• what we working on
• what we have tested

all of these resolved issues are deployed in test server so our client can review them.

we found this is very collaborative and simple. more over it has less overhead to manage. it is so visual that daily (end of the day) reporting is not restricted to any specific person. anyone can do it.

best wishes,

reposted on my personal blog