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)

_____

http://kenschwaber.wordpress.com/2012/07/25/self-organization-and-our-belief-that-we-are-in-charge/

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

_____

http://scrum.org/Forums/aft/206#838

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

http://blog.cromwellhaus.com/2012/01/time-box-a-holistic-view-on-sprints-and-iterations/

_____

http://cromwellhaus.com/2012/02/time-box-get-stuff-done-tool-for-risk-reduction-focus-and-decision-making/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%253A+RyanCromwell+%2528Ryan+Cromwell%2529

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.

Capacity Planning - GASP

A GASP is a generally accepted Scrum Practice.

This is another issue where it's not wrong or right. It is a difference in approaches. I feel that a more mature scrum team does not need, and will not want to, plan by hours. I have coached teams to strive towards that. Teams forecast at the story level. We always have. (Well we used to commit!) We just use the hour estimates on tasks to verify that we are not thinking crazy. Over time we will just be able to eyeball if we can get things accomplished. I like the concept of doing it from the beginning. Pushing the team to maturity earlier than later is my suggested path.

Remember to take time and think about what value new methods provide. In this case, the team commits either way. No need to waste time with hour estimates. I suggest conservative commitments when they do this. Then a gradual push to see where they can get to. When they find their limits they will know their velocity. If they pull in more than they committed to, the customer team wins! The PO also wins in that the product team will be able to deliver a Release Plan really fast because there is not a great deal of time used in finding the velocity based on hours. If the PO does not deliver the Release Plan fast, then it is my experience that the Release Plan gets delivered to the PO.