ryanlevell
commented
1 year ago FYI: Reading the EPUB version (for page reference on iPhone Books app [differs on Mac Books app])
Page 16-17
To make things crystal clear, if a team passively receives documents in a hand-over, regardless of what they are called and whether they are on paper, in a wiki or in a ticketing system, that's not really working with user stories. Organisations with such a process won't get the full benefits of iterative delivery.
Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations, and don't waste too much time nailing down the details upfront. Engage business stakeholders and delivery team members in a discussion look at a story from different perspectives and explore options. That's the way to unlock the real benefits of working with user stories.
Page 25:
The Connextra card template ('As a... I want ... So that') is a great structure for a discussion token. [...] But that's not the only way to start a good conversation. As long as the story card stimulates a good discussion, it serves its purpose. Write down who wants something and why they want it in any way you see fit, and do something more productive with the rest of your time than filling in a template just because you have to. For example, make sure that the person in question is actually a stakeholder, and that they actually want what the card says.
Page 28:
Focus on the problem statement, the user side of things, instead of on the software implementation. The way to avoid trouble is to describe a behaviour change as the summary. For example 'Get = profit overview faster', or 'Manage deliveries more accurately'.
Page 29-31:
The value of software is a vague and esoteric concept in the domain of business users, but task size is under the control of a delivery team, so many teams end up choosing size over value. This results in technical stories, that is, stories that don't really produce any outcome, and a disconnect between what the team is pushing out and what the business sponsors really care about.
Many delivery teams also implicitly assume that something has value just because business users are asking for it, so they don't question it. Robert Brinkerhoff, in Systems Thinking in Human Resource Development, argues that valuable initiatives produce an observable change in someone's way of working. [...] In essence, translating Brinkerhoff's idea to software means that it's not enough to describe just someone's behaviour, but we should aim to describe a change in that behaviour instead.
The story was perceived to be of value because the business stakeholders had asked for it. It was a strange situation, because the story was purely technical - a division of a background task. [...] The value statement was 'being able to import contacts'. The problem was that the users were able to import contacts already, and they would still be able to import contacts after the story was done - there was no real success criterion. We tried to capture the value not just as a behaviour, but as a change in that behaviour, and the discussion suddenly took a much more productive turn.
Page 34:
Try to quantify expected changes - a good change is one that is observable and measurable. Effectively, once you have identified a change, ask How much?'
Page 39:
Even if the required system behaviour is accurately described, the amount of work required from the team to implement it depends on how much it differs from the current system behaviour, and this might not be clear to everyone. In many cases we also need an 'instead of' clause to follow the 'I want'.
Page 42:
Test whether the verb is the right one by asking negative questions. If the change is expressed as 'I want to access the reports using a mobile device' you can ask 'Is it the case that you can't access the reports at the moment?' If the answer comes back as Well, I can already access the reports, but I have to use the website instead of the application' then the verb is the wrong one. It would be better to say 'I want to use a native application when I access the reports'.
'In order to notify traders they are nearing trading volume limits, the system will warn traders when the total volume reaches within 10% of the daily trading limit, whereas currently there is no warning message and trading continues until the daily limit is exceeded at which point all trades are blocked'.
Page 45:
Stories shouldn't be small because they need to fit into an iteration, but because the world shouldn't end just because a storv turns out to be wrong. [...] The key questions for story sizing shouldn't be about the iteration length, but about how much business stakeholders want to invest in learning whether a proposed change will actually give them what they assumed.
Page 46:
By approaching stories as survivable experiments we can shift the focus from technical complexity to expected outcomes and learning. This prevents technical stories, stories that are too small to go live and stories that business sponsors don't care about.
Page 53:
Avoid 'as a user' statements like the plague. Avoid overly generic customer segment descriptions of any kind.
Page 57:
A good guideline is that the user need of a story (In order to...') should ideally be in the sphere of influence of the delivery team, and the deliverable (I want...") should ideally be in their zone of control. This is not a 100% rule and there are valid exceptions, but if a story does not fit into this pattern it should be investigated. When the user need of a story is in the zone of control of the delivery group, the story is effectively a task without risk, which should raise alarm bells. There are three common scenarios: The story might be fake, micro-story or misleading.
Page 62:
If vou discover stories that are only partially actionable by your team, consider splitting them into a part that is actionable by the delivery group, and a part that needs management intervention or coordination.
Page 76:
Creating a hierarchical backlog can also stop the team and stakeholders from turning delivery into a stream of consciousness and never dealing with big risks. Once a hierarchy is in place, stakeholders can prioritise at a level higher than stories, for example by picking impacts.
As an aside, please don't use activity metrics such as velocity or burn-down scope to measure progress. They only show that people have been busy, not that they were working on the right things or even producing something valuable.
Page 82:
Try to divide your plan into several tiers, and then avoid breaking down a higher-level item until you complete all the relevant lower-level stories for the previous higher-level item. Plan for asteroids - some will be huge, some will be small, but give yourself space to manoeuvre. Until you clean up the first big item completely, there is no point attacking the other big items. Keep things in a hierarchy so you can monitor, discuss and report on the big- picture items.
Page 90:
Impact maps nicely organise the information held in the popular Connextra user story card format ('As a . in order to... I want...'). Visually, the second level of an impact map corresponds to the persona or role of a user story. The third level corresponds to the value statement, especially when teams use the idea about focusing on behaviour changes. The fourth level corresponds to the deliverable, or the scope statement.
Impact maps have three primary advantages over alternative techniques - they are visual, collaborative, and simple.
Congrats on starting Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans, Tom Roden, I hope you enjoy it! It has an average of unknown/5 stars and 0 ratings on Google Books.
Book details (JSON)
```json { "title": "Fifty Quick Ideas to Improve Your Tests", "authors": [ "Gojko Adzic", "David Evans", "Tom Roden" ], "publishedDate": "2015-05-15", "description": "This book is for cross-functional teams working in an iterative delivery environment, planning with user stories and testing frequently changing software under tough time pressure. This book will help you test your software better, easier and faster. Many of these ideas also help teams engage their business stakeholders better in defining key expectations and improve the quality of their software products.", "image": "http://books.google.com/books/content?id=Re3FsgEACAAJ&printsec=frontcover&img=1&zoom=1&source=gbs_api", "language": "en", "pageCount": 124, "isbn10": "0993088112", "isbn13": "9780993088117", "googleBooks": { "id": "Re3FsgEACAAJ", "preview": "http://books.google.com/books?id=Re3FsgEACAAJ&dq=intitle:Fifty+Quick+Ideas+to+Improve+Your+User+Stories&hl=&cd=1&source=gbs_api", "info": "http://books.google.com/books?id=Re3FsgEACAAJ&dq=intitle:Fifty+Quick+Ideas+to+Improve+Your+User+Stories&hl=&source=gbs_api", "canonical": "https://books.google.com/books/about/Fifty_Quick_Ideas_to_Improve_Your_Tests.html?hl=&id=Re3FsgEACAAJ" } } ```