CTO/CIO. Ruby. Rails.
just some more awesome
The overarching goal is to reduce the feedback loop.
Features and Scenarios
----------------------
Features and Scenarios are difficult. It is time consuming and draining. Accept this. It is especially painful because we have never done this.
The planning phase will be the most difficult phase of any project. Variables and unknowns are at their highest during this phase.
Depending on the scope, it is not unusual for a team to spend a whole day for its initial planning session. Then, to spend an hour a day for its first few weeks to re-plan.
This may feel unproductive. It's not. The team is doing all these things to make the next phases more productive.
On being correct
----------------
You are the most wrong about the project right at this moment. The objective is not to be 100% correct now. The objective it to be more correct tomorrow. Then, more correct the next day. And, so on.
Do not get hung up on being 100% correct right now. Get 80% there. Then, move on. Tomorrow, come back to it. Get is 81% correct. Then, move on.
Reduce the feedback loop.
On writing
----------
Writing the scenario forces us to think about what we want. It is easy to wave your hands, and talk. When you write it, you have to be precise and clear. As they say, talk is cheap. Also, you want to produce a working document for the other stakeholders in the project.
On language
-----------
Language and words matter. At times, this may feel like you are arguing over sematics. If there is disagreement over the wording of a scenario, this usually means that there is a gap in the information. For example, is there a difference between 'integrating' and 'communicating'? Or, 'batch' and 'cron'?
Use the "As a, I want, So that" and "Given, When, Then" formats. It is a good tool to help the team focus on the desired behavior, not the implementation.
"Setting up more DB connections" is not the best behavior statement. "Increase page load time by 5 seconds" is a better description of behavior. And, I think that could be improved even more. But, I'll try that tomorrow after I know more.
Reduce the feedback loop.
Some tips
---------
Try this if your team is struggling:
1. Write down the high level Features.
2. Assign a Feature to each team member.
3. Disband.
4. Each team member writes scenarios (Given, When, Then's) for their feature.
5. Reband.
6. Pick a Feature and Discuss the scenarios.
7. Edit as needed.
You may notice some of the following:
- Lots of overlap. This is good to reveal now! Remember the 'I' in INVEST.
- Wildly varying degrees of specificity. Usually, this is because of a team member writing the implementation of a scenario rather than the behavior. Again, this is good. Figure it out now.
- Some Features have very little scenarios. This may indicate that the Feature is not a stand alone Feature. Maybe, it is a scenario in another Feature.
- No one understands the scenario you wrote. This can mean that the Feature was not understood by the team. Or, it can mean the language and words are imprecise.
Remember: Reduce the feedback loop.
CTO/CIO. Ruby. Rails.
CTO/CIO. Ruby. Rails.
Theme created for Posterous by Obox
