Understanding features in Scrum – The never ending feature
A couple of years back I blogged about the difference between features and user stories in Scrum, you can read the whole article here. Since then there has been allot of discussions among Scrum enthusiasts on the topic, where my article has been referenced, eg this discussion on StackExchange.com. My understanding on the differences between features and user stories has not change, but I though I post a copule of updates to clarify some on the topic.
This is the second update on the topic, my first update was called A testable user story.
In this post I will try to address another aspect of the feature, namely the difficult task of creating or defining the correct set of features! In my other post I used login functionality on a web site as an example, and will use the same example here. Please read the posts A testable user story and Features vs user stories to better understand the concept of user stories in the context of features.
A testable user story
A couple of years back I blogged about the difference between features and user stories in Scrum, you can read the whole article here. Since then there has been allot of discussions among Scrum enthusiasts on the topic, where my article has been referenced, eg this discussion on StackExchange.com. My understanding on the differences between features and user stories has not change, but I though I post a couple of updates to clarify some on the topic.
This is the first update on the topic of testable user stories, my second update is called Understanding features in Scrum.
Cynefin Framework in the context of agile vs. waterfall
The Cynefin Framework was developed by Dave Snowden back in 1999, and has since then been used in numerous situations and businesses to describe problems, situations and systems. The Cynefin Framework is a practical application of complexity theory to management science. The framework helps managers determine the prevailing operative context, enabling appropriate choices and decisions (ref Wikipedia).
The never ending religious discussion of agile vs. waterfall can hopefully be a little bit more nuanced seen in the context with the Cynefin Framework
Timeboxing in Scrum
The concept of timeboxing in Scrum is a critical factor for success. Without any timeboxing we quickly end up with inefficient development process, too much overhead and very low velocity. From day one it is therefore important to use the time boxing in Scrum as an effective tool to keep the teams velocity as high as possible.
Scrum is like a game of Backgammon
The first time I learned the rules of backgammon, I was quite surprised by the simplicity of the rules. But as I read some more about backgammon I quickly came across the saying: "Backgammon: A minute to learn a life-time to master", and as I started playing more and more I came across new rules like The Crawford Rule, doubling and a lot of strategy principles! Gradually I realized that the key principles I learned about backgammon is merely a fundament, getting good requires hours and hours of training!
A couple of years later (2005), I came across Scrum for the first time and had some of the same feeling. The principles are few, are theory is very easy to understand! But as I started using scrum, first as a team member, and later as a Scrum master I discovered a never ending series of hard to handle problems and challenges. Today I see my self as an experienced Backgammon player and Scrum Master, but realize that both require both theoretical skills and years of experience!
Here I will present a couple of principles that can help you become a more valued scrum master!
Features/Epics vs. user stories in Scrum
UPDATE: This post has become very popular lately, and has been referenced on several discussion forums. Please also read my follow-ups to clarify the subject even more:
- Follow-up 1: A testable user story
- Follow-up 2: Understanding features in Scrum
As Scrum has grown in popularity, the concept of user stories has made its way from theory and dust covered UML books, to developers every-day vocabulary. In the "old days" we tended to focus on one layer at a time, instead of one user story at a time, we focused on writing large classes supposed to solve all possible scenarios for later re-use instead of simple YAGNI focused classes pin-pointing its purpose and we focused on large-upfront design instead of gradually adapting to the maturity obtained by the customer (and developers) through the project.
We started out with allot of user-stories and even more good intentions, but ended up with phase 2 and 3 and a bunch of long forgotten concepts and diagrams. Today we are not better at planning one year ahead; we have just realized that this is almost impossible. We started focusing on business value which closely relates to user-stories. We started working with user stories weekly and we started estimating and prioritizing user stories in our Product Backlogs.
Daily Stand-Ups in Scrum
I just came across a great summary of the daily stand-ups in scrum, written by Joakim Karlsson. I guess most Scrum teams start out with good intentions and focus in the begging, but as time goes by, we start falling into the old "around the table" reporting habit to the project manager, the Scrum master becomes more and more a project manager, and we gradually drift away from the core principles and ideas behind the daily stand-up!
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© Copyright 2013
Paul Eie
Sponsors
Tag Cloud
Sponsors
Archives
- March 2013 (1)
- February 2013 (4)
- January 2013 (2)
- November 2012 (4)
- October 2012 (1)
- March 2012 (1)
- February 2012 (2)
- January 2012 (1)
- December 2011 (1)
- November 2011 (1)
- August 2011 (1)
- June 2011 (1)
- May 2011 (2)
- April 2011 (6)
- March 2011 (1)
- February 2011 (1)
- January 2011 (1)
- November 2010 (3)
- October 2010 (1)
- September 2010 (2)
- July 2010 (2)
- June 2010 (2)
- April 2010 (3)
- March 2010 (3)
- February 2010 (3)
- January 2010 (7)
- December 2009 (8)
- October 2009 (1)
- September 2009 (1)
- August 2009 (1)
- July 2009 (1)
- May 2009 (2)
- January 2009 (1)
- February 2008 (1)