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.
This article should be seen in relation with my previous checklist post. Finding an effectiv daily and weekly work rythm is essential to obtain productivity and replace a stressful reactive career with a proactive career where you set the agenda, avoid firefighting and finish the tasks you define as important, not what everybody else defines as important!
A couple of important principles:
- Start the day by making a prioritized list of the most important tasks for today!
- Always finish your most important task each day before making any phone calls or checking emails! This is very important, checking emails makes everybody else agenda more important than yours, and you loose control of your day at that very second you check your email.
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!
Releasing new software will always involve some risk of failure whether you do it small incremental releases, or you do it in large cycles with comprehensive testing. There are however some key principles that will help you lower your risk of failure, principles which are easy enough to remember, but which we often don't follow for one reason or another......