After we complete the Vision, we must develop the Product Backlog. (Please go to this post for an overview of what I think Release Planning includes.)
There are two parts to this.
First, we must define the Roles to use in the User Stories.
Second, we must write User Stories. I call this second part a User Story Workshop.
Let's break this down.
Assumption: We have a new team that is doing Agile-Scrum for the first time.
Who: We want the whole team of pigs (PO, SM, and implementers). And the BSHs (business stakeholders). Usually you want the 3-5 best business stakeholders you can get. They are never perfect, but at least they are the best you can get. The Product Owner is usually the main person driving which BSHs to bring in.
The Product Owner is leading the content. The ScrumMaster is leading the facilitation.
What: We want about 5 to 7 roles. These are the roles to go in the User Stories.
And then we often want about six months of work for some good release planning. (In some situations, we want more or less work.)
If we want about 6 months of work, lets do some math. My rule of thumb is 8 stories per 2 week Sprint. 6 months work is 13 sprints. 13 x 8 = 104. Now, those stories are all small enough for a Sprint. So, in Release Planning, we can be pretty happy with 50 stories (average about twice as big as a Sprint-sized story). So, this gives us a rough idea of what we are shooting for. Of course, we will learn a lot later, and can make many adjustments.
So, we only need about 50 stories that cover about 6 months worth of work.
How: Brainstorming to get 5-7 roles can be easy or can be hard.
We mostly want different user types (roles), end users of the system or product. But more generally, we want any role that would want some feature in the product. Even if they don't (directly) use the product.
(Note: These are not the roles of the Scrum team members. A fairly common question.)
Some teams will come up with 30 roles. Some will come up with only 2. We want to either synthesize or break down until the number of roles gets in the 5-7 range. Something magic about that number. But not worth dying for.
Whatever they do, it will probably work the first time. But it will become better as they start to get practice with stories, and appreciate, tacitly, the characteristics of a good story.
OK. Now, with the Roles, the whole team starts to write stories. We let them self-organize. We give them 15 minute timeboxes. At each 15 minute break, they "check in." They inspect progress and see if they want to adjust anything. Usually they see that they want to write stories faster.
Typical productivity for a team is to average about 1 story per minute. So, in about 50 minutes.....50 stories.
When they feel finished, we recommend having the whole team gather around all the stories (imagine them on a wall). They should look at them, and try to see what needs improving the most. Maybe a few aren't worded well. Maybe a few need the INVEST criteria a bit tighter. Maybe two team members identify 3 missing stories.
What were the INVEST criteria?
* Independent (we try to maximize this, but we never can make all stories independent)
* Negotiable
* Valuable
* Estimable (clear enough that we feel effort can be estimated)
* Sized Appropriately
* Testable
It is sometimes useful to get more sophisticated. I don't like to do that the first time. They need to get one cycle of just doing the basics. Probably several cycles.
We recommend that the PO answer questions and talk about the product that he envisions. But let the others identify the specific stories. He gets them more engaged. They get more creative. They have better motivation.The PO can always add or modify later (if there work is imperfect).
Why?
Why do we have all the pigs and the business stakeholders?
Several reasons I will mention.
1. We want the whole group to share whatever tacit knowledge they have with the rest of the group.
It turns out that everyone has some knowledge or ideas to share. Or at least some good questions. Well, almost everyone (yes, there are a few exceptions sometimes on this one.)
2. We want the group to create knowledge together. And share it together.
A bunch of things happen has they create knowledge. One is that they all start to form a similar mental picture (or pictures) of the product and the effort and things related to it (eg, the architecture).
3. We want the team to develop motivation together.
Finally, having been involved in the creation, the whole thing becomes their 'baby.' This is far better motivation than we get from 'the mushroom treatment,' which is de facto the most common thing. (The mushroom treatment is where the team is kept in the dark and fed manure -- this is great for growing mushrooms, not so great for growing teams.)
Yes, it is somewhat expensive to have everyone involved. But the payback during the project is very high. Very high. And the time to market is better.
Time Box: As indicated, I like to have a series of 15 minute timeboxes, where the team checks in. Are we going too fast or too slow? Anything we should change? Who is talking too much, who too little?
Usually the whole thing can be done is 60-90 minutes. But really it is not a problem if it goes 120 minutes. Or even more. The main thing is, as SM, if one guy gets talking and worrying, and nothing is getting done, you can't let the team just spin. Someone must fix it, and get them productive again.
Common Issues: I like brainstorming rules. Meaning: Anyone can create anything, and for this timebox (say, 15 mintes), no critique is allowed. Then an editing or 'fixing' timebox, where the team reviews and improves the roles or stories. Then another 'create anything' timebox. And so on.
I find creating one story and then criticizing each one is too slow, and inhibits the team too much. Especially beginning teams.
Another issue is having only one person write the stories. If a team really wants to do this, it is not terrible. But things usually go faster if everyone writes.
Not sharing. I think it is useful if, as a person writes a story, he shares it with the group (says the words of the story out loud). That way, no one writes the same story a second time.
Top Down/Bottom Up. I find some people are top down thinkers and other are bottom up thinkers. It takes both kinds. Let them be who they are. Especially while they create. Rather obviously, top down thinkers will tend to write epics that need to be broken down (even at this point we can often see some epics are just too big). And bottom up guys will write stories that sometimes are too small. And we sooner or later need to combine stories.
User Story format. I like it and encourage it. They especially tend to forget the "so that" clause. So I encourage them to include it. But, if they just can't think of the feature in a user story format, I say: ok, just write something as a PBI (product backlog item). Maybe later we will convert that into user story format. Be easy on the beginners. They are just learning to ride the bike.
Results. Usually the team ends up with 40-60 stories that represent 5-7 months worth of work. Ballpark. (It is just a gut feel at this point.) Which is a great start for the Release Planning.
These user stories (or PBIs) are just the right middle level of 'features' for everyone to have a clear enough picture of what the product will be. It embodies the vision. It makes things concrete for people, without getting mired in details. Wonderful. And they can do this the first time.
Is it perfect? No. Could it ever be perfect? No. Is it a reasonable time to spend to get a level of 'quality' (in all aspects) that it very useful? Yes!
Can we write more stories, if we discover them, later in Release Planning? Yes! And it always happens! And will we add more stories as we are doing the Sprint? Yes, always.
There are two parts to this.
First, we must define the Roles to use in the User Stories.
Second, we must write User Stories. I call this second part a User Story Workshop.
Let's break this down.
Assumption: We have a new team that is doing Agile-Scrum for the first time.
Who: We want the whole team of pigs (PO, SM, and implementers). And the BSHs (business stakeholders). Usually you want the 3-5 best business stakeholders you can get. They are never perfect, but at least they are the best you can get. The Product Owner is usually the main person driving which BSHs to bring in.
The Product Owner is leading the content. The ScrumMaster is leading the facilitation.
What: We want about 5 to 7 roles. These are the roles to go in the User Stories.
And then we often want about six months of work for some good release planning. (In some situations, we want more or less work.)
If we want about 6 months of work, lets do some math. My rule of thumb is 8 stories per 2 week Sprint. 6 months work is 13 sprints. 13 x 8 = 104. Now, those stories are all small enough for a Sprint. So, in Release Planning, we can be pretty happy with 50 stories (average about twice as big as a Sprint-sized story). So, this gives us a rough idea of what we are shooting for. Of course, we will learn a lot later, and can make many adjustments.
So, we only need about 50 stories that cover about 6 months worth of work.
How: Brainstorming to get 5-7 roles can be easy or can be hard.
We mostly want different user types (roles), end users of the system or product. But more generally, we want any role that would want some feature in the product. Even if they don't (directly) use the product.
(Note: These are not the roles of the Scrum team members. A fairly common question.)
Some teams will come up with 30 roles. Some will come up with only 2. We want to either synthesize or break down until the number of roles gets in the 5-7 range. Something magic about that number. But not worth dying for.
Whatever they do, it will probably work the first time. But it will become better as they start to get practice with stories, and appreciate, tacitly, the characteristics of a good story.
OK. Now, with the Roles, the whole team starts to write stories. We let them self-organize. We give them 15 minute timeboxes. At each 15 minute break, they "check in." They inspect progress and see if they want to adjust anything. Usually they see that they want to write stories faster.
Typical productivity for a team is to average about 1 story per minute. So, in about 50 minutes.....50 stories.
When they feel finished, we recommend having the whole team gather around all the stories (imagine them on a wall). They should look at them, and try to see what needs improving the most. Maybe a few aren't worded well. Maybe a few need the INVEST criteria a bit tighter. Maybe two team members identify 3 missing stories.
What were the INVEST criteria?
* Independent (we try to maximize this, but we never can make all stories independent)
* Negotiable
* Valuable
* Estimable (clear enough that we feel effort can be estimated)
* Sized Appropriately
* Testable
It is sometimes useful to get more sophisticated. I don't like to do that the first time. They need to get one cycle of just doing the basics. Probably several cycles.
We recommend that the PO answer questions and talk about the product that he envisions. But let the others identify the specific stories. He gets them more engaged. They get more creative. They have better motivation.The PO can always add or modify later (if there work is imperfect).
Why?
Why do we have all the pigs and the business stakeholders?
Several reasons I will mention.
1. We want the whole group to share whatever tacit knowledge they have with the rest of the group.
It turns out that everyone has some knowledge or ideas to share. Or at least some good questions. Well, almost everyone (yes, there are a few exceptions sometimes on this one.)
2. We want the group to create knowledge together. And share it together.
A bunch of things happen has they create knowledge. One is that they all start to form a similar mental picture (or pictures) of the product and the effort and things related to it (eg, the architecture).
3. We want the team to develop motivation together.
Finally, having been involved in the creation, the whole thing becomes their 'baby.' This is far better motivation than we get from 'the mushroom treatment,' which is de facto the most common thing. (The mushroom treatment is where the team is kept in the dark and fed manure -- this is great for growing mushrooms, not so great for growing teams.)
Yes, it is somewhat expensive to have everyone involved. But the payback during the project is very high. Very high. And the time to market is better.
Time Box: As indicated, I like to have a series of 15 minute timeboxes, where the team checks in. Are we going too fast or too slow? Anything we should change? Who is talking too much, who too little?
Usually the whole thing can be done is 60-90 minutes. But really it is not a problem if it goes 120 minutes. Or even more. The main thing is, as SM, if one guy gets talking and worrying, and nothing is getting done, you can't let the team just spin. Someone must fix it, and get them productive again.
Common Issues: I like brainstorming rules. Meaning: Anyone can create anything, and for this timebox (say, 15 mintes), no critique is allowed. Then an editing or 'fixing' timebox, where the team reviews and improves the roles or stories. Then another 'create anything' timebox. And so on.
I find creating one story and then criticizing each one is too slow, and inhibits the team too much. Especially beginning teams.
Another issue is having only one person write the stories. If a team really wants to do this, it is not terrible. But things usually go faster if everyone writes.
Not sharing. I think it is useful if, as a person writes a story, he shares it with the group (says the words of the story out loud). That way, no one writes the same story a second time.
Top Down/Bottom Up. I find some people are top down thinkers and other are bottom up thinkers. It takes both kinds. Let them be who they are. Especially while they create. Rather obviously, top down thinkers will tend to write epics that need to be broken down (even at this point we can often see some epics are just too big). And bottom up guys will write stories that sometimes are too small. And we sooner or later need to combine stories.
User Story format. I like it and encourage it. They especially tend to forget the "so that" clause. So I encourage them to include it. But, if they just can't think of the feature in a user story format, I say: ok, just write something as a PBI (product backlog item). Maybe later we will convert that into user story format. Be easy on the beginners. They are just learning to ride the bike.
Results. Usually the team ends up with 40-60 stories that represent 5-7 months worth of work. Ballpark. (It is just a gut feel at this point.) Which is a great start for the Release Planning.
These user stories (or PBIs) are just the right middle level of 'features' for everyone to have a clear enough picture of what the product will be. It embodies the vision. It makes things concrete for people, without getting mired in details. Wonderful. And they can do this the first time.
Is it perfect? No. Could it ever be perfect? No. Is it a reasonable time to spend to get a level of 'quality' (in all aspects) that it very useful? Yes!
Can we write more stories, if we discover them, later in Release Planning? Yes! And it always happens! And will we add more stories as we are doing the Sprint? Yes, always.
No comments:
Post a Comment