Skip to main content

Posts

Showing posts with the label Sprinting

13+2 Sprint Cadence

Sprint length - a fun debate. What is the best practice - a funny question. There is no best practice for sprint length.  But what factors should go into the decision? The team's ability to become predictable within the sprint duration. The Product Owner's ability to plan and to commit to the unknown of not changing the plan for the sprint's duration. The frequency of needed feedback on the direction the team is making toward the release goal. The ability of the team to create their sustainable pace. Many team's I've worked with have trouble defining their sustainable pace .  I've argued that this pace that allows the team to deliver both working software that is potentially shippable each sprint and to have high quality deliverables along with team learning is quite a bit below the teams typical sprint velocity. When teams are under extreme pressure to deliver they typically forget one of the 7 habits of effective people - to sharpen the saw .  S...

The Holiday Stratagem

What do the Thanksgiving and Christmas holidays do to your teams tempo and cadence? For most US teams this holiday period from mid November to after the first of January is hectic and disruptive in various ways.  This calls for a Holiday Stratagem.  A trick to allow the team to have some semblance of continuity and flow during these times. The Sontaran Stratagem - Doctor Who To discuss this stratagem let's first define some terms: Tempo - the rate of workdays to calendar days Cadence - the beat of the sprint events to fall upon the same calendar day of the week Sprint duration -  in work days (in this example I'll use 10 work days) Sprint length - the length of calendar days between two sprints (14 days for the example 2 week sprint) What do you value more?  The ability to deliver more work in the short term -or- the ability to predict long term the capability of the team to deliver that work?  Or perhaps something else, like teaching a new te...

Velocity Calculus

Velocity Calculus  -- by David A. Koontz In the practice of Scrum many people appear to have their favorite method of calculating the team's velocity.  For many this exercise appears very academic.  Yet when you get three people and ask them you will invariability get more answers than you have belly-buttons.  That in its self is an interesting phenomenon, worthy of a blog post.  But this is not it. Calculus is the mathematical study of change. This video is a photo journal simulation describing how to calculate a Scrum sprint velocity.  It explains the calculus for one of the most difficult decision a team faces.  What to do with that first unfinished story.

It is not about Sprint Zero; Think Sprint-N

There is a good dialogue on the topic of Scrum's Sprint Zero going on at  Scrumdevelopment@yahoogroups.com .  If you follow the group you will surely learn something about Agility.  It will just seep into your pores.  Go right ahead - click the link and join up... I'll wait here. The "raging" debate in the Scrum world for years is - should a Scrum team have a Sprint Zero?  A sprint in which they get setup for doing real work.  A sprint for installing all that infrastructure (DB, Version Control System, App Server, build a few [sarcasm] frameworks). [Hint: when a developer says they just need to build a framework - it is geek-code for I don't have any idea how to use The Google to find a tool to do that job - so I will have to forge my own special handmade tool - check back with me after I reinvent the wheel.] I think perhaps the wise and wonderful man behind the curtain - Ron Jeffries - captures the best thinking on the topic: I do, however, obj...

Chefs of Fruit Salad (Scrum Immersion Exercise)

Chefs of Fruit Salad immersion exercise is designed to give the participants a quick shared experience of Scrum sprinting in a domain (food preparation, presentations and delivery) that is familiar to everyone but slightly outside the expertise of many.  This domain requires most individuals to use similar techniques to battle the uncertainty of requirements and implementation details while allowing for great creativity within their skill sets.  In game design it is a leveling of the field of play - making most everyone an beginner, with some deep skills in the recesses of their experiences (hasn't everyone eaten a very decorative fruit salad at a fancy restaurant or conference)? The exercise as a whole gives the participants an experience of using the Scrum terminology and practices (stand-up meeting, timeboxes, planning, reviews, retrospectives) within a safe environment to learn and play.  Within this safe environment people feel free to create the mental models the...