How should a scrum team count the story points for user stories (product backlog items) that are started in one sprint but completed in a later sprint? This question comes up frequently and has surprisingly deep implications. It also has a simple answer. Let’s dive into an example that a client sent me.
Read the full article…
I was inspired to create a retrospective game for agile teams, based on the game Dixit. Dixit is a game that makes use of picture cards. Each of these cards has an unusual drawing on it. The Agile Learning Labs team used it recently in one of our sprint retrospectives and it worked well. Give it a try with your team and leave a comment to let me know how it works for you.
This is the last of five installments in my series on splitting large user stories into smaller user stories. If your scrum team isn’t able to complete a minimum of four user stories every week, then start with the first installment and work your way back to this one. Occasionally, I find a user story that I cannot split using conjunctions, generic words, or acceptance criteria. When this happens, I use timeline analysis.
With this technique, I ask my stakeholder to pretend the user story is already done, and then I ask “What happens when the functionality gets used?” They will then describe a sequence of events. Even for things that happen non-deterministically, or which could happen in parallel, they still describe it sequentially; it’s just the way our brains and our language work. I then identify the verifiable steps in the timeline.
Read the full article…
This is the third in my series on splitting larger user stories into smaller user stories. If you are just joining us, go back and read part one and part two. Don’t worry, I’ll wait right here for you.
Like the first story splitting technique (Conjunctions and Connectors technique), the second technique (the Generic Words approach) works by parsing the text of the user story. This time, instead of looking for connector words, we are looking for generic words. “What’s a generic word?” you ask. Any noun that isn’t a proper noun is generic, as are many verbs, adjectives, and adverbs. What we are looking for is a generic or general term in the story which could be replaced by several more specific terms to create a number of smaller stories.
Read the full article…
As I described last week, splitting large user stories into smaller user stories has many benefits for the scrum team and the business. We also agreed that before we try to split a user story, we want to write it in the traditional format:
As a <type of stakeholder>,
I want <the deliverable>,
so that, <some value is created>.
A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate, and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.
When a team’s user stories are smaller, they complete stories more frequently. This is good on many levels. Each time a story is completed the team has delivered value, which is what the business pays us to do. We also get many types of feedback with each completed story. We can update our release (storypoint) burndown chart and get important schedule feedback, allowing us to inspect and adapt the schedule. We also get product feedback every time we finish a story. We have something new to show our stakeholders and they can give us feedback and guidance so we can adjust the product plan, to better build the product our stakeholders desire. Additionally, we get technical and architectural feedback. It isn’t until we have working user stories that we can see how well the technical and architectural choices we have made are serving us. If our original ideas are not working out as we had hoped, then we will need to adjust the architecture to better support the functionality being developed.
Read the full article…
One of my fellow Certified Scrum Trainers, Henrik Kniberg, created this excellent video that describes agile software development from the point of view of the product owner. I’m really impressed, and I regularly share this with the participants in my Certified Scrum Master and Certified Scrum Product Owner workshops. Great job Henrik!
Hi Chris. It was great to have you in Beijing and you provided us with awesome Certified Scrum Master and Certified Scrum Product Owner trainings. We are having internal discussions about the role of quality engineers in scrum. Should they be on the scrum teams? Do we need quality engineers if we are doing scrum? If we have them, who should manage them? Should we move them around from team to team?
In Integrum, Chris talks to Roy van de Water and Drew LeSeur of Integrum about running Agile Learning Labs as a transparent company with a radical compensation plan, writing The Elements of Scrum using scrum, and how our new book, Scrum: A Breathtakingly Brief and Agile Introduction is an iteration of our first one.
Roy and Drew ask some excellent and hard questions, so tune in and give a listen!
Since this article was first published, The Team Estimation Game has evolved into something even better: Easy Estimation With Story Points. If you are looking for a fast and effective way to estimate, we recommend going straight to that article. If want to know where Easy Estimation With Story Points came from, keep reading.
The Team Estimation Game plays like a game, but it accomplishes valuable work: assigning story point estimates to user stories.
Teams using this technique are typically able to estimate 20 to 60 stories in an hour. The game was invented by our friend and colleague, Steve Bockman. Here is how one team plays the game:
Read the full article…