今日推荐开源项目：《奇怪人头 avatar-generator》
今日推荐英文原文：《It’s time to start writing useful User Stories!》
今日推荐开源项目：《奇怪人头 avatar-generator》传送门：项目链接
推荐理由：在各种社交平台帐号上都提供了头像更换的功能，为了达到不和别人撞头像的目的，这个项目提供的各种自定义头像就很适合解决问题。它提供了类似于捏脸一样的头像生成方式，通过自定义各个部位来完成属于自己的独特头像——或是丢开一切，按一下全部随机按钮来享受缘分与艺术结合的创作成果。
今日推荐英文原文：《It’s time to start writing useful User Stories!》作者：David Pereira
原文链接：https://medium.com/serious-scrum/its-time-to-start-writing-useful-user-stories-29445eb83405
推荐理由：在开发需求过程中的一种方法：用户故事
It’s time to start writing useful User Stories!
Five simple tips for turning User Stories around from pointless to great!
“Can we break the user story up into the front-end and back-end?” a developer asked during the backlog refinement session.The first time I got this question, I said, “No, because the user story needs to deliver value to the end-user.” However, I always got the same question during the backlog refinements. I wondered, “Maybe I am doing something wrong with the User Stories.”
I couldn’t understand what was going on. The User Stories were well written with precise acceptance criteria. I reflected over it for a while, and then, suddenly, I had the A-ha moment! The User Stories were more than an invitation for a good conversation. They were requirements!
Individuals and interactions over processes and tools — Agile ManifestoDuring my journey as a Product Owner, I came across some typical issues with user stories. When I solved these misunderstandings the results skyrocketed. I would like to share the misunderstandings and their solutions so you can do the same.
What are User Stories
Let’s first understand what User Stories are. In bold, you can read the essential aspects.- User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. — Mike Cohn, User Stories
The changing point happened once I understood the purpose of User Stories; collaboration. Everything is about conversations around the desired functionality.
“A great Product Backlog Item starts a conversation. The goal of this conversation is to establish a common understanding.” — Maarten Dalmijn, Great Product Owners write awful backlog items
1 — One step at a time
User Stories should have one single goal. Therefore, the word “and” is not welcome while writing User Stories. Imagine a platform like Airbnb, let’s prepare a User Story for the filters:As a traveller
I want to filter accommodations by price, category and size
So that I can find precisely what fits my wishes
Great Product Owners aim to increase value as soon as possible, when adding multiple goals into a User Story, we do the opposite. So always ask: Does this User Story represent a single objective? If the answer is no, then divide it!
Considering our example, we could write three User Stories instead of one. Each filter can deliver value alone, and they have no dependencies, which gives the Product Owner the chance of prioritizing each item in a different moment.
“Big achievements come one small advantage at a time, one step at a time, one day at a time.” — Jim Rohn
2 — Use clear words within the acceptance criteria
Product Owner: I think the search needs some rework. It is not fast enough, in my opinion.Developer: I don’t think so. For me, it is fast. It loads in less than three seconds.
In a discussion like this, “fast” has different meanings for the Product Owner and the Developer. Therefore, User Stories should have precise words. Avoid unclear terms as much as you can, when you notice you are falling into this trap, ask, “How can I measure the result?”
Let’s consider our previous User Story. The following acceptance criteria is an example of what not to do.
- The search result is quickly presented to the user
- The search result is presented to the user in no more than 3 seconds
Photo by David Travis on Unsplash
3 — Don’t forget the invisible part
The crucial part of User Stories is never written; it’s the conversation with the team that matters the most. Without exchanges within the development team, User Stories are pointless.Keep in mind that User Stories are not requirements; they are an invitation to a good conversation. Therefore, Product Owners should not describe solutions, but rather present problems to the Development Team. Then, a pleasant conversation flows, which leads to collaboration and a meaningful solution.
A common misunderstanding is to write detailed User Stories, which discourages the Development Team from starting a conversation. I used to write precise User Stories. Surprisingly, the only question I got was about breaking User Stories into technical boundaries. Avoid this pitfall, write just enough to encourage the team to have a great conversation.
I spent a lot of time writing User Stories. It made me feel great when all tickets were clear and the Development Team did not ask questions. I thought my developers should be happy with my effort and detailed explanations.
Except that I was all wrong. I would now consider my backlog items to both be bad and wasteful at the same time. — Maarten Dalmijn, Great Product Owners write awful backlog items
4 — User Stories are written from the user perspective
Many teams forget a vital part of User Stories. It’s written from the end-user perspective. I guess the end-user doesn’t care about front-end, back-end, and so on. Yet, many teams insist on breaking User Stories into technical boundaries.- It’s time to shift our focus from delivering tasks to maximize the value.
Photo by Kelly Sikkema on Unsplash
Why do the teams want to split User Stories into tech boundaries? Generally, because some Developers like having the User Stories assigned to them. Thus, being able to reach the status of “done,” then burning the story points. Be careful with this scenario. Scrum Teams should focus on collaborating. Individual performance does not matter; what matters is the result of the team.
A good story is one that goes through an entire technology stack. Or at least as much of that technology stack as is needed to deliver the feature. Stories split along technical boundaries gives us stories that don’t deliver any value to users on their own. A frontend (say, a web interface) does users no good until it is paired with a backend (a middle tier and/or database).
To avoid falling into the trap of splitting a story along technical boundaries, see if you can instead split the story based on the paths through the story. — Mike Cohn, Five Story-Splitting Mistakes and How to Stop Making Them
5 — Forcing everything into User Stories
A common mistake is: writing everything as User Stories. The backlog should be comprised only of User Stories is a myth. Let’s take a look at what the Scrum Guide says about the Product Backlog:The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. — The Scrum Guide, November 2017
As you can see, the Scrum Guide does not mention how the Product Owner should maintain the Product Backlog. Which means we are on our own. We have the flexibility to define as it works best in our context.
I am a supporter of User Stories. However, it doesn’t mean we should write every single Product Backlog Item as a User Story. Some tasks just don’t go with the User Story format. Great Product Owners don’t lose the focus of maximizing the value. The point is, the Product Backlog should contain items that are understandable by the team.
Let’s explore one example of what not to do:
“As the Development Team, we want to have a backup routine for our database, so that in case of failure, we can recover the data.” Let’s be honest. This User Story is pointless. We can keep it simple: “Configure the backup routine for every 30 minutes.”. Be careful with too much focus on User Stories. Sometimes just some keywords would be enough.
The forced nature of ‘User Stories’ is especially obvious in non-IT environments. Meant to capture functional requirements in applications, the template isn’t all that useful outside of IT. It often leads to weirdly phrased or vague internally-oriented items, like “As marketeer I want to send a mailing to group X so that they are aware of new products” or “As team member I want to write a plan to see how Y can be done”. We prefer to ask non-IT teams to focus on putting the outcomes they want to achieve on the Product Backlog, not what they are going to do, e.g. “Notify group X of new products” and “Strategy for achieving Y”; — Barry Overeem, Myth 4: In Scrum, the Product Backlog has to consist out of User Stories
Wrap-up
User Stories are amazing once we understand the essence of it. Remember, it’s no more than an invitation to a good conversation. Some tips that will help you to benefit the most from User Stories.- Write measurable acceptance criteria
- The conversation with the team is the most important part
- Write from the user perspective. Do not break into tech boundaries
- Do not force everything into User Stories, understand where it makes sense and where it doesn’t
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
