Thursday, March 30, 2006
Now What?
Okay, you have the stories written down containing enough details. You've told the developers about the necessary details, without setting them on stone. Is there anything else to do?
A good story is one that usually leaves the reader satisfied -- may it be a fairy tale, a suspense novel where the bad guy is revealed, or something that ends in "happily ever after". But we all know that there are some stories that need a sequel. Think of a story when you were a kid that you loved to extend, and expound upon, or make up stuff about.
Role playing games rally around the notion that stories are built around quests. When you finish a quest, you're sucked into another one. It's no different from stories that we write for the software developers -- since fulfilling a story leads to another story.
In the previous days, I wrote about writing clear simple stories, and writing complete simple stories. Today, I'm writing about sequencing these simple stories.
Defining which stories are related to each other is nice -- you can make a great big story built of many different small stories. You can mix and match these small stories and reorder them to make completely different big stories. But you'll run into a brick wall when you find out that these stories don't necessarily need to be told in sequence.
What?! You just told me we're going to put them into a sequence?! I did. But that doesn't mean that the sequence of the small stories to form the big story will determine the sequence in which they will be built. It does however tell us about which stories are related, to allow us to determine which set of stories are most important.
How does this happen? It's important for the customer to determine which big story to realize first. This is again so that we can determine which set of stories (not necessarily related stories) we want realized first. Important decisions like these come into planning sessions, especially when developers are falling behind in delivering stories for the latest development iteration.
Imagine this (bear with me here, I don't know a lot of fairy tales): Cinderella and Sleeping Beauty are living in different parts of the continent. They both have the same prince (let's just imagine, please) but the prince has only until midnight to slay a dragon and wake up Sleeping Beauty, or do the last dance with Cinderella. This wouldn't be too much of a problem if he had all day to slay the dragon, but unfortunately it's 10 pm and he has to make a decision.
In this situation, the prince can continue on with the "Slay the Dragon" story and do the "Dance with Cinderella" story after that (and leave Sleeping Beauty until the next day). Or if the director wants to finish the "Wake Up Sleeping Beauty" story first, then Cinderella will have to wait until the next midnight taping, and reschedule the bippity-boppity-boop magic for next time (which might cost her a lot).
The point is, someone has to make a decision. In this case, the director (or producer, or someone else) has to make a choice and tell the prince what to do, and which story to finish first. And the prince doesn't have to decide for himself, so that he doesn't get in trouble.
Aha! Yes, that's the point. The developer doesn't have to get in trouble (or too much trouble at least) for decisions that the customer has to make. This way, the developers will know what they should be working on when the end is near -- so that the little time they have will be channeled to the more important things to be delivered.
Grouping related stories together, or those that might depend on each other is a good way of determining which things may or may not come first, as well as attribute priority to these stories. This exercise is usually done to keep everyone's sanity and let everyone in on the big picture -- which is always a good thing.
Important decisions made by people make people important. Keeping important decisions to the important people gives people importance -- and value of the decisions affect the value of people.
A good story is one that usually leaves the reader satisfied -- may it be a fairy tale, a suspense novel where the bad guy is revealed, or something that ends in "happily ever after". But we all know that there are some stories that need a sequel. Think of a story when you were a kid that you loved to extend, and expound upon, or make up stuff about.
Role playing games rally around the notion that stories are built around quests. When you finish a quest, you're sucked into another one. It's no different from stories that we write for the software developers -- since fulfilling a story leads to another story.
In the previous days, I wrote about writing clear simple stories, and writing complete simple stories. Today, I'm writing about sequencing these simple stories.
Defining which stories are related to each other is nice -- you can make a great big story built of many different small stories. You can mix and match these small stories and reorder them to make completely different big stories. But you'll run into a brick wall when you find out that these stories don't necessarily need to be told in sequence.
What?! You just told me we're going to put them into a sequence?! I did. But that doesn't mean that the sequence of the small stories to form the big story will determine the sequence in which they will be built. It does however tell us about which stories are related, to allow us to determine which set of stories are most important.
How does this happen? It's important for the customer to determine which big story to realize first. This is again so that we can determine which set of stories (not necessarily related stories) we want realized first. Important decisions like these come into planning sessions, especially when developers are falling behind in delivering stories for the latest development iteration.
Imagine this (bear with me here, I don't know a lot of fairy tales): Cinderella and Sleeping Beauty are living in different parts of the continent. They both have the same prince (let's just imagine, please) but the prince has only until midnight to slay a dragon and wake up Sleeping Beauty, or do the last dance with Cinderella. This wouldn't be too much of a problem if he had all day to slay the dragon, but unfortunately it's 10 pm and he has to make a decision.
In this situation, the prince can continue on with the "Slay the Dragon" story and do the "Dance with Cinderella" story after that (and leave Sleeping Beauty until the next day). Or if the director wants to finish the "Wake Up Sleeping Beauty" story first, then Cinderella will have to wait until the next midnight taping, and reschedule the bippity-boppity-boop magic for next time (which might cost her a lot).
The point is, someone has to make a decision. In this case, the director (or producer, or someone else) has to make a choice and tell the prince what to do, and which story to finish first. And the prince doesn't have to decide for himself, so that he doesn't get in trouble.
Aha! Yes, that's the point. The developer doesn't have to get in trouble (or too much trouble at least) for decisions that the customer has to make. This way, the developers will know what they should be working on when the end is near -- so that the little time they have will be channeled to the more important things to be delivered.
Grouping related stories together, or those that might depend on each other is a good way of determining which things may or may not come first, as well as attribute priority to these stories. This exercise is usually done to keep everyone's sanity and let everyone in on the big picture -- which is always a good thing.
Important decisions made by people make people important. Keeping important decisions to the important people gives people importance -- and value of the decisions affect the value of people.
