Feature funny business
•Download as PPTX, PDF•
2 likes•300 views
This document discusses how to write effective features in Agile development. It provides guidance on defining features, including that a feature should be distinctive, prominent, and solve a problem or meet an objective for personas or stakeholders. It also recommends including a purpose statement, scope, benefits, acceptance criteria, assumptions, risks, estimates, and timelines when defining a feature.
Recommended
More Related Content
Similar to Feature funny business
Similar to Feature funny business (20)
More from Mike Burns
Recently uploaded
Recently uploaded (20)
Feature funny business
- 2. Feature Funny Business Mike Burns – Agile Coach, Tatts Group
- 3. As a < persona >, I want < some goal / context > so that < the “why” >
- 4. |
- 6. As a < persona >, I want < some goal / context > so that < the “why” > Persona is wrong / unknown / not useful Goal / context is wrong / unknown / not useful The “why” is only meet the “rules”, it doesn’t mean anything 3Cs of a User Story • Card • Conversation • Confirmation No “global” personas list to select a persona from No understanding of the context in relationship to other stories The “Why” is not traceable or relatable to a higher goal (e.g. Project/Product Goal) References: • https://help.rallydev.com/writing-great-user-story Feature is hard to write No good definition or template to follow Story is broken down from a not-so-good feature Not enough training / coaching
- 9. A feature is a distinctive and prominent attribute of a solution. distinctive prominent attribute solution
- 10. Xmas Halloween Fancy Dress Scary Mask Bunny Costume Serve Food Christmas Cake Pumpkin Pie Have Great Seasonal Festivities Santa Suit Features vs Themes A feature is a distinctive and prominent attribute of a solution. A theme is for grouping and additional metadata/context.
- 11. “Rules” of a Feature A feature • sits in the work item hierarchy, e.g. Goal -> Feature -> Story. • should be estimable. • should be able to be placed on a timeline with approximate start and end dates or appropriate milestones. • can be broken down into many (more than 1) stories (or epics). • provide a perceived value to a group(s) of stakeholders. * As with every “rule”, these are made to be broken and there will always be the exception.
- 12. Inventory Management Book Management Magazine Management Search Filter List Show ‘Inside Book’ Search Login Display Products Login Reporting Shopping Cart Be the world’s largest bookstore By the end of the year, we will sell all our products online. Purchase Products Credit Card Purchase Books A feature is a distinctive and prominent attribute of a solution. • In the work item hierarchy • Estimable • Milestones • Broken down • Valuable
- 16. Hi my name is: Feature
- 18. • Primary – users who work regularly and directly with the product or solution • Secondary – users who support the primary users of the product or solution • Tertiary – users who use the results of the system being used, usually decision makers • Facilitators – users who focus on design, development and maintenance of the product or solution
- 26. Display Products Inventory Management ReportingPurchase Products Jacinta Product Manager Dan Customer Sharon Warehouse Manager Will Finance Manager Run End of Month Report Purchase with Visa Add Book to Store Catalog Select Book From Catalog Send Purchase to Customer Run Stock Report Alert Warehouse of New Stock
- 29. A feature is a distinctive and prominent attribute of a solution.
- 30. If your stories stink, check the fish head. Thank You!
- 31. Fin.
Editor's Notes
- What I consider a feature to be. Why I think features are core to writing good stories Techniques for writing better stories through writing better features
- Hands up if you have seen this before? We have all been taught to fish – we know that this is simple and it works. Hands up if you have seen a template for a feature? Not many, if any, why is that?
- Often I hear teams wanting to write that unicorn story – the one that is so awesome and unambiguous, can be completed within about half the iteration, works with a cross functional team, but most importantly, it delivers real value. Sadly, we don’t see many unicorns. And what happens is that teams actually end up with a poisoned story that eats into the teams ability to deliver. My job as a coach is to help move teams back along the spectrum.
- First some context. At Tatts we see the work item hierarchy like this… Epics are a special case – an epic is just a big story that is yet to be broken down.
- Problem: Writing not-so-good user stories A story is a placeholder – 3Cs of a user story, card, conversation, confirmation Why is this so hard?? 5 Whys
- Old saying, “the fish rots from the head”. If you are having trouble writing “good” user stories, maybe the problem is higher up. It could be the Goal or even the Strategic Objective, but for now we are only considering Features.
- Definition breakdown: distinctive - to distinguish it from other features within the solution prominent - important; something that “generally” the solution cannot do without attribute - a technical or non-technical part that gives value to stakeholders or users solution - something that solves, or is a method for solving, a problem or achieves a goal
- Themes are a scrum term to define groups of related stories. Often the stories all contribute to a common goal or are related in some obvious way, such as all focusing on a single customer. However, while some stories in a theme may be dependent on one another, they do not need to encapsulate a specific work flow or be delivered together. That’s nice, and there is a place for that too – but they sit outside the hierarchy as additional metadata that can give more context but it doesn’t describe where it came from.
- Should be estimable - usually as a relative (or T-shirt) size. In time frames, it should be greater than an iteration & less than 6 month - typically ~1 month. If larger than 6 months it is a candidate for review and is likely to be a separate project with differing goals. Stakeholder - where a stakeholder can be one or more people or roles Perceived value as value is in the eye of the beholder – you must define what value means for this feature
- A company has an objective to “be the world’s largest bookstore”, and to meet this they have a goal of “selling books online”. A project is started that aims to build a solution, made up of features, to achieve the goal. One distinctive, technical, attribute of the solution would be a way to manage inventory. The “Inventory Management” feature is very important and the solution cannot do without it. It may include epics like “Book Management” and “Magazine Management”. Conversely, "Search" is not a feature; although not optimal, we don't need a search feature for the online bookshop to work. The solution could use a 3rd party online search engine, or display a large list of books that the user can scroll through. “Search” may end up as an epic within a “Display Products” feature, alongside “Filter” or “Show ‘Inside’ Book”. As we cannot do without displaying the products. “Login” is also not a feature as we can sell books online without an account. Without being able to buy a book we cannot achieve the "selling" part of the goal, therefore the solution cannot do without it, the feature could be a "Purchase Products“. “Reporting” is a feature that is important to the running of the business, however to meet the goal of “selling books online” the solution can do without it. This feature is exceptional and ‘breaks the rules’. Although we can do without it, it is a distinctive technical attribute, that is important to running the business, and therefore can be a feature.
- Begin with the end in mind If your features are written by someone outside of the core team and you are told to use them - don't. Analyse and rewrite them based on what is a good feature and what is meaningful to the team as it will ensure that you have good stories, and a good project.
- Don't write features alone! Collaboration is the key to good features.
- A template is often a good way to ensure that all the right questions are asked at the right time. Agile teams have long used the "As a…I want…So that" template for user stories but features often end up loosely structured at best. Subsequently the required data is missing or incomplete, leading to user stories that are difficult to relate to their parent (which ultimately means that they are difficult to relate to the project goal and in turn strategy). Also, features can span multiple personas, so trying to force into a user story template with only one persona (one persona, one thing, one time) just won't work.
- Feature Name: <start with a verb, e.g. manage, protect; or end with a noun that denotes an action, resulting state, or condition, achieved by adding -ment, -ion, or -ise to a verb, e.g. management, protection> If you have a series of features that are all prefixed with the same thing, e.g. Show results - Brand A, Show results - Brand B, they are probably the same feature - or mostly they are epics within a feature.
- Summary: This feature will… <what problem is it solving / what is the objective>
- Personas: <who is it solving a problem for / who benefits from it (See hints below on the types of personas)> Use Personas to Discover the Right Stories Personas are extremely important as ensure that we are looking at the problem from all the right angles. There are four types of personas: Primary – users who work regularly and directly with the product or solution Secondary – users who support the primary users of the product or solution Tertiary – users who use the results of the system being used, usually decision makers Facilitators – users who focus on design, development and maintenance of the product or solution Most features have at least primary and secondary personas. Review your features after eliciting the user stories, if not all the personas in the features are represented in the stories then there is a problem.
- Scope: <when does it solve the problem / where does it solve the problem / how often does it solve the problem / what is the context of the change>
- Benefits: <once the problem has been solved what difference do we see> If any section of the feature starts to list things out, they are probably the start of stories - capture them, but do it somewhere else. What will the stakeholders be able to do/see/use once the feature is implemented.
- Acceptance Criteria: <what makes it the solution right (not just done, but done right)> Test your features against the acceptance criteria after each story has been tested. This will ensure that the stories are focused in the right areas and are leading towards the goal of the project.
- Assumptions: <what did we take for granted>
- Risks: <what could go wrong>
- Estimated Size: <T-Shirt sizes: S=~2 weeks, M=~1 month, L=~3 months (and if required XL= ~6 months - see hints)> If they are too big (bigger than 3-6 months' work) then they might be a separate project or maybe there is a better way to split it. Often it seems like we're being pedantic about size but in my experience having the right sized and correctly worded features makes a big difference in to how your stories are subsequently written.
- Planned Start/End Date / Milestones: <used for high level planning + capacity planning>
- We can use well written features to map out and validate our stories against the different personas. What I’ve shown you is “early” life cycle thinking about features. Features will change, be removed, and new ones created. The techniques here can also be used throughout the lifecycle.
- Here is an example
- This proposed template can also work with non-functional features. Non-Functional requirements should be scheduled for delivery alongside end-user features. Non-functional features describe how the system works, such as security, regulatory, reliability, maintainability, scalability, and usability (often referred to as the “ilities”) (http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/).