Scrum/Kanban - Adding User Story Between Sprint

Add a new Story in current Sprint.. lot of buzzz around on multiple pages/blogs.
This is a good discussion. My thoughts to this buzz topic  are few folds here:

1. Adding User Stories between Sprint is one way of Iteration Planning called as 'Commitment Driven Planning' (Source Mike Cohn book Chapter 14).
2. Adding  User Stories between Sprint comes when there is a High Priority Items come in picture due business priority changes (possible scenario in real world).
3. Adding  User Stories between Sprint should be an exception and not a habit.
4. Well in such cases, it is certainly legitimate to:
• Happy Scenario - Remove less priority stories from current Sprint Backlog ('To do' List) and pull a new story of size of similar size. E.g
• Here if need is to add E as high priority item to the board, team will remain open and take it as  “Feel free to add E to the 'Todo' column and remove either C or D in that case and pull 'E' in the top item from To Do”.

• Ok Scenario - Remove less priority stories from current Sprint Backlog ('In-Progress' List) and pull a new story of size which can fit in remaining available time. Well this may have few additional work to rollback any code changes taken, but not impossible). Also this will impact final Sprint velocity, however will be understood by management and you'll gain browney points too for being agile).

More reference: 

• Scrum/Kanban - http://www.infoq.com/minibooks/kanbanscrum-minibook
• Mike Cohn - http://synchronit.com/downloads/freebooks/Agile%20Estimating%20and%20Planning.pdf

In nut-shell, being Agile, we need to be mature to handle real time scenarios and remain open for 'Commitment Driven' planning at times and gain maximum business satisfaction.

Please feel free to share your thoughts if any.
Also I'll try to add more references to this post.

Keep Blogging...

Arun Manglick

Sprint - Days Of The Week

This post is about what is perfect for Sprint Start/End Tenure/Days of the week.

When I first started managing agile projects, my teams routinely started their iterations on a Monday and ended them on a Friday. We’d do this whether the specific team was using two-, three-, or four-week iterations.

Mondays seemed like a natural day to begin an iteration and Fridays were an obvious day to end on.
Well this sometime or most of the time does not work, as any last minute issues resulting team to work on weekends and again get ready on Monday filled with meetings for next iteration .. Ufff.. Leaving no space to drinks or bowling..

I suggested to change their mind about this and began coaching team for more happy path.

To accommodate this, we decided to run two-week iterations that would start on a Friday and end on a Thursday. This worked wonderfully.

• Fridays (Between Sprint Day) were divided in half
• First half -  Spent doing last minute left-over, an iteration review, retrospectives and in planning the next iteration. This usually took until mid-afternoon most.
• Second half -  Here team would either get started on the work of the new iteration or they would occasionally head out for drinks or bowling.

The iteration would start in earnest the following Monday. This was great because there was no dread of a Monday filled with meetings, as there was when Monday was review and planning day.

The team also benefitted by occasionally using Friday morning to wrap up any last minute work they’d been unable to finish on Thursday.They didn’t make a habit of this and it only happened a few times; however, spending a few hours on a Friday morning wrapping things up was preferable to coming in over the weekend (as they would have done with a Monday iteration start).

This approach made team having Thu-Evening/Fri-Morning most logical time to deploy/release. If something went wrong, they could fix it Thu-Evening/Fri-Morning rather weekend and keeping a good work-life balance.

Source- Mike-Cohn (Iteration Planning)

Keep Blogging..

Arun Manglick