All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers. For a Scrum overview, please see Agile Overview. This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.
Choosing Themes
At project initiation, the team will meet in order to determine the themes and goals of the project. In determining these themes, many factors will need to be considered. These themes will also need to be estimated and prioritised so that the development team knows what to build. These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done. The owner will determine the themes, but the developers will aid in this choice. Developers can help this decision by indicating the risk level or dependencies of each theme. These themes are often written on Index cards and should be considered at a high level of abstraction, such as:
- As a user, I require the ability to add new cars so that I can manage my growing stock.
- As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
- As a user, I want the software to record my high scores so that I can try and beat other scores.
Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.
Prioritising Themes
Themes should be chosen by the owner, but this decision should be guided by the development team and result from considering the following factors.
Value
First and foremost, the project’s primary incentive is likely to be financial. The cost of the project (as determined by the cost of each theme) should be weighed against the potential return in order to determine fiscal value.
Knowledge
It is unlikely that a project will exist solely to deliver new information, but themes can certainly be chosen on the impact that they have on company or team knowledge. Certain themes may have the potential to reduce uncertainty or improve the delivery of other themes.
Risk
Risk is a big, but often overlooked, factor when determining theme prioritisation. Risk can come in many forms, such as not completing on time or being unable to obtain certain tools. Uncertainty is also a risk, a completely new problem domain represents a very high risk factor as the team will not have first hand knowledge of the problem. It is recommended that risk and value are assessed for each theme, and that knowledge gain be used as a linear factor. The grid below can be used to ascertain the position of these items.
Place the themes on the above grid, it can be useful to specify the value scale in financial terms, if you have estimated the themes.
High Risk/High Value: Do first. This reduces risk and generates high value.
Low Risk/High Value: Do second. This doesn’t reduce much risk, but generates the highest value remaining.
Low Risk/Low Value: Do third. This is almost option and could represent some of your “Would like to haves”.
High Risk/Low Value: Don’t do. It is not worth tackling a high risk item without the appropriate reward.
Customer Desirability
When determining which features or themes to develop first, users can be queried using the Kano model. This model describes potential features in the following ways:
Must haves
Must have features, such as a bed in a hotel room.
Linear
Features that increase customer satisfaction the more than there is, such as space in a hotel room.
Delighters
Features that the customer did not expect, but that provide high satisfaction. Such as complimentary wine in the room.
These types can be charted, as seen below in the diagram from Wikipedia.
As seen here, the lack of basic needs (Must haves) will not satisfy the customer, increased levels of linear features will improve satisfaction and delighters will provide a good boost to satisfaction.
The way to determine which category a feature falls into is to ask the customer about the presence of a feature in both a negative and a positive way. The customer then answers using the following scale:
- I like it that way
- I expect it to be that way
- I am neutral
- I can live with it that way
- I dislike it that way
An example of both the functional and dysfunctional form could be:
- If a user can print their car list, how do you feel?
- If a user cannot print their car list, how do you feel?
The answers are then aggregated using the following table:
| Dysfunctional | ||||||
| Like | Expect | Neutral | Live with | Dislike | ||
|
Functional | Like | Q | D | D | D | L |
| Expect | R | I | I | I | M | |
| Neutral | R | I | I | I | M | |
| Live with | R | I | I | I | M | |
| Dislike | R | R | R | R | Q | |
- M – Must have
- L – Linear
- D – Delighter
- R – Reverse
- Q – Questionable
- I – Indifferent
Customer answers can then be aggregated and distributed in order to find the most common for each feature, giving a good indication of what features would be most desirable to clients.
Splitting Themes or Stories
Initially, stories may be quite large and will act as placeholders until such time that thy are included in the following sprint. At this point, it will often be appropriate to split the story into constituent stories so that the team will have a greater understanding. Splitting stories is a team for improving understanding in readiness for development or in order to improve the quality of an estimation. Stories may also need to be split if the item will not fit into a single iteration. Stories can be split using the following methods.
- Split large stories along the boundaries of the data supported by the story
- Split large stories based on the operations that are performed within the story
- Split large stories into separate CRUD operations
- Consider removing cross cutting concerns (such as security, logging, error handling etc…)
- Consider splitting a large story by separating the functional and nonfunctional aspects into separate stories.
- Separate a large story into smaller stories if the smaller stories have different priorities.
- Don’t split a large story into tasks. Instead, try to find a way to fire a tracer bullet through the story.
- Avoid making things worse by adding relating changes to an appropriately sized story unless the related changes are of equivalent priority.
With the backlog built up, you are now ready to move on to planning the release of the product.