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 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.
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
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.
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!
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:
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.
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!