In the thick of it...

I have the good fortune of being at Scrum Gathering 2013. I love being around my people. The atmosphere of so many others who are interested in all things Agile is way cool.

I arrived at registration and and was give my badge and what was called my "Scrum Bag". (hilarity!) I thought that was just a name that people called me... Our name badges could have tags hanging off them that denoted how many times you had leveled up on the Scrum Alliance path. I did not put anything on my own. I am glad I chose to do this. When I speak to someone here, they look at my badge, and ask me questions. It is a great conversation starter. Since I like talking to people this is a win!

I have had the chance to see lots of awesome people who I have met in my agile journey. It is only the first day and I have had my mind Blown by Lyssa Adkins and Michael Spayd on AQAL and how it impact Coaching an Agile Enterprise. I have had a cool session with my original CSM trainer, Angela Druckman on diagnosing problems in an agile organization. The link is to the Kindle Version. The real paper one on Amazon is stupidly priced. 

I have had the chance to visit the restaurant Lotus of Siam, and tonight will go to Border Grille in the Mandalay Bay. 

Looking forward to more cool stuff tomorrow...

Adding more content...

I have totally been struggling with consistent blogging. I have ideas that I think would make good topics. They go through my head all day. I just do not seem to have the time or focus to act on posting them.

I have decided to add a few more of my interests here. I love technology and personal productivity. Sometimes I just like plain old weird stuff. This, of course, will not assist me in time or focus towards posting. It will, however, give me a wider range of stuff not to post.  ;-)

What should have Story Points?

A fellow ScrumMaster posted the following question on a board on a popular career related site.

I had a discussion with my interviewer about if there is some technical related work( indirectly related to the story in sprint) should have a story point value or not! My thought is 'anything done in sprint should have a story point value.' Any thoughts?

I still believe the purpose of story points is to represent the Product Backlog. The items in the Product Backlog represent increments of Business Value to our customers. I believe that the points are a forecasting tool for the Scrum Team to use historical performance to estimate future expectations. If that is the case, and I am a Product Owner; wanting to give expectations to my customer, stakeholders, and organization, I will want to see decreases in velocity from Sprints were we worked on things other than Business Value that our customer approves of and requests from us.

I do not suggest Story Points for anything except for stories. If you track hours at the task level, then I suggest putting hours towards tasks unassociated with the Sprint goal "on the board" for these types of items. If you do not then you will deliver less of the Product Backlog in that Sprint.


We just need more time...

I recently had the question of should/can we extend a Sprint. I am pretty Anti on extending Sprints.  This is a GASP that I treat as a pretty standard rule. I will search high and low for an alternative to extending a Sprint. I did not put much personal input into this post, I did add what I sent out in relation to the practice. 

Some articles on Sprint Extension (they are anti-too)


Ken Schwaber = Instead of extending, what can you get done?


Don McGreal is a pretty respected coach locally.  Don = I would certainly avoid extending the Sprint or creating sicktime/holiday PBIs.


These are articles suggested by Scrum.Org on time boxes.


Abnormal sprint termination (PO Decision)

From the Scrum Guide 2011

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog Items are reviewed. If part of the work is potentially shippable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning Meeting to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.