An interesting user story case, any comments or opinions are welcome.

It doesn't look to me as though any user stories have yet been identified. What we can see, perhaps, are design decisions masquerading as user stories.

I've never known a user want to log in so they can use an application, for example. Doing so is actually a barrier and inconvenience to them. What they do want is to achieve an outcome, via a useful application, in a secure way. The stories you describe are the voice of an architect speaking and the journey has consequently been one of design optimization.

Hi Ian, 

Thanks for your comments.

This is a young Scrum team. The average working experience of developers is only two years.

In addition to their accumulated experience, most of their knowledge sources come from practical examples.

The following example user stories were written to describe the functionality in an early version of the Scrum Alliance website.

...

As a moderator, I want to create an account for the application by entering my name, email address, a password and a username so that I can start using the application.

As a moderator, I want to log in using my account name and password so that I can start using the application.

As a moderator, I want to change my account details so that I can keep my account details up-to-date.

As a moderator, I want to delete my account so that account information and games are no longer stored.  

As a moderator, I want to see dates and times in my local timezone so that I don't have to do timezone conversion myself.

...

 Doing so is actually a barrier and inconvenience to them. 

This is a cloud storage system. Rather than saying that the "login" requirement is an inconvenient design, I think it is to protect the data uploaded by users from malicious access.

What I find interesting is not whether the user stories were well written.

It's that young Scrum teams often encounter some documents that are not clearly written, or the words seem to contradict each other.

I listened to them to share and communicate throughout the whole process.

Everyone has reason and can show evidence.

For example, the document says that the user story should be as small as possible. Right?

Some people also argue that the user story should be modified to make it consistent with the code.

Some people think that there is no need to change it. Anyway, it can meet the Sprint Goal, and the cooperating users can also accept the current performance. Isn't it good?

What I see is the growth of a Scrum team, not how well the user stories are written.

I would say that the Scrum Master needs to modify User Stories. The User Stories are coming from the Product Backlog, which is in the responsibility of the PO. When it moved to the Sprint Backlog, it is owned by the Development Team, but I would not let them change the Story without the PO.

If the story only says they want to log-in and the next is saying I want to see my directories and this is implemented but taking long, the story is still met, isn't it? Would be a first increment to show how it could look like. The PO can then ask to make it faster or scale up for more users.

Other than that it would be part of Refinement and Planning for the DevTeam to understand what needs to be done and clarify with the PO if this Story is ready and then also to discuss how this can be done and how it will be estimated. Latest in the Planning the DevTeam should consider how to do it and if the SM has knowledge, he may of course distribute to that discussion as well, for example to guide into the direction to load everything when logging in.

Sorry, of course in the first sentence I meant 

I would say that the Scrum Master does not need to modify User Stories.

I see 2 issues worth considering.

1. The point of the user story is not the template even though that is what we tend to know about it... On top of that, there are lots of product backlog items we should not even consider formulating from the user's point of view. Just for fun,

The SMART: "As a search engine user, I want to see the search results ordered by relevance in order to see the most relevant results first."

The paranoid: "As a bank account user, I want my data to be depersonalised on the risk modelling platform so that when a related data breach occurs my personal details will not be exposed."

The cynical-masochist: "As a social media user, I want my data to be sold to autocratic regimes in order to be targeted with fake news."

The high-handed: "As a financial regulator, I want my reports to be served from a new data platform in order to... correction, on order."

Pretty useful stories, aren't they? Of course, we should replace the 'user' by another actor when it makes sense, however, lots of times even that would not help much. Using the template for a data migration project can only result in facepalming/teammooduplifting solutions. If we drop the template and do not insist on involving a user perspective in everything, we can still benefit from the features of a 'good' story. There can be any business or technical rationale behind a requirement which has nothing to do with particular users. Or we may end up with shareholder stories.

2. Agile development is not just incremental but also iterative. Thus we should go back to already implemented solutions and improve (and refactor) them as needed. Furthermore, the lack of upfront design does not mean we should not rely on the already known. In this case, I bet the authentication blueprint did not see an evolution spanning over multiple Sprints. There is no need to pretend that all stories were invented independently, especially when there are genuine dependencies. At least as long as we can have potentially releasable increments in the end.

The first thing that stands out to me is that none of those example User Stories are good stories. I'm not sure if something got lost in translation from Chinese to English, but they don't get into why the actor wants to do things. Why does the member want to start using the application? Why does the member wat to manage directories or browse files? As they are written, they look more like functional requirements in a different format. They also seem to get into details of what to build rather than describing a problem and letting the team devise appropriate solutions to them.

The fact that the development standard weren't met isn't an issue with the stories, but some other aspect of the development process. I'd want to know why the violations of the guidelines weren't detected earlier. Was the original developer aware of them? Did code reviews highlight the problem? Why didn't performance testing of the stories find an issue?

However, I'm not sure why you would need to modify the stories. They were designed, implemented, tested, and delivered. If they didn't work as intended, then you would write bugs or new stories to describe how the system should behave and implement those. It's possible to maintain user stories over time, but I really haven't seen a case where that's a useful way to spend time and effort.

@Tim

If the story only says they want to log-in and the next is saying I want to see my directories and this is implemented but taking long, the story is still met, isn't it? 

Yes,  if the PO does not write the acceptance criteria for the user story.

@Sean

Furthermore, the lack of upfront design does not mean we should not rely on the already known.

There is no need to pretend that all stories were invented independently, especially when there are genuine dependencies. 

 100% agree. This is exactly what the newly formed Scrum team needs to learn.

@Thomas

Agree with your opinions.

I may need to add

1. This is a young team with an average of 23-24 years old. The most senior has only three years of development experience.

2. This case occurred during the Sprint, and the person who assisted in the test was from the customer service department.

If it is after the end of the Sprint, the problem is relatively simple, just add a user story to deal with it.

But when the problem occurs during the Sprint, and the Product Owner already knows the problem, what should be done? I chose to let them discuss how to deal with it.

Modify User Stories? Or leave it to the Retrospective meeting for discussion?

Are these User Stories considered Done? Or not Done?

Of course, there will be many issues that can be discussed in the upcoming Retrospective event.

Personally I like the INVEST criteria as a guideline for good user stories. The idea is that you try to meet all the criteria without violating another. The letters stand for Independent, Negotiable, Valuable, Estimable, Small and Testable

Take the S, which stands for small. You are right when you say you should make user stories as small as possible. This is related to queueing theory and kanban. Having smaller batches will increase your flow. So that is a good thing. However, making things small should not go at the cost of the other values.  

Your example story about getting the permissions list is not typically valuable to a user. They just want to be able to access the system so they can do what they need to do. It is a technical implementation of an invisible action taken by your application, making it also not really easily testable.

I'm not sure if putting links to other websites is tolerated here, but you should find a wikipedia page with some more info about the INVEST criteria if you search for "Invest mnemonic".

@Ching-Pei Li

Yes,  if the PO does not write the acceptance criteria for the user story.

The PO doesn't need to write the acceptance criteria himself. If anybody in the scrum team sees that something is not right, but doesn't act because the PO didn't write it down, then you have a problem in your team. The PO is a member of your scrum team. You are all in this together. Don't be an arse.

Modify User Stories? Or leave it to the Retrospective meeting for discussion?

Never postpone learning.

Are these User Stories considered Done? Or not Done?

That depends entirely on your Definition of Done. If they meet all the criteria you've defined for yourself, then yes. It may be a good idea to have a good look at your DoD during a retrospective though.

In addition to their accumulated experience, most of their knowledge sources come from practical examples.

The examples taken from the Scrum Alliance are bad examples, I'm afraid. To me they sound like "As a user type I want to do something so that I can do it. You don't want to do something so you can do it. You want to do something because you want to achieve a goal.

A better example could be "As a moderator, I want to be able to change my account details so that the forum members know clearly who I am and can contact me if they want to inquire about my moderating decisions."

Or "As a moderator, I want to be able to change my account details so that significant changes in my personal or professional life can be clearly reflected in my profile".

You may notice that changing the goal you are trying to achieve may affect the design decisions the team makes when developing the story. In case of the first story, the team may want to allow changing of the attributes that are used by forum members to get into contact such as email address or contact forms. In case of the second story, the team may want to allow changing job title, last name (in case of marriage), etc.

What is your role on the team?

Given the general inexperience of the team in development experience, I'd likely take the guess that they have very little experience in Scrum. When a team is less experienced or less mature in good practices, they need more active coaching. In the context of Scrum, this means close involvement with the things that the team is doing - attending the Daily Scrums at least as an observer and working with the Product Owner on Product Backlog management and teaching good refinement techniques.

If I was this team's Scrum Master, I wouldn't have let them consider these stories unrefined. They don't the good characteristics of requirements nor commonly accepted good characteristics of user stories. The problem shouldn't have occurred during the Sprint because these work items should never have been pulled into a Sprint in the first place. That means more coaching of the Product Owner when the Product Backlog Items are written before refinement and then coaching of the team in how to refine them effectively and make sure that the work is ready for a Sprint.

Without seeing the team's Definition of Done, I'm not sure if the work is Done. If it's been designed, delivered, and integrated, it should be Done work. At the same time, the work doesn't meet the team or organizational standards. Perhaps these standards are not incorporated into the Definition of Done or there isn't the right work happening to ensure that the Definition of Done is met.

The Retrospective is the right place to talk about all of this with the team.

@Henri

Your example story about getting the permissions list is not typically valuable to a user.

It may be that this case is special. For this product, the Permissions List is very valuable to users. Users can decide which files to share with others, and can set sharing permissions. Similarly, the user can also know who has shared files with her/him and what s/he can do with these files.



 

@Thomas

I am not a member of this Scrum Team. I am an architect and stakeholder. :)

Thank you for your enthusiasm and valuable response.

Most documents teach us how to decompose user stories, but rarely teach us how to integrate user stories.

For the product owner, these user stories are indeed made by real users.

For developers, they are indeed implementing functions based on user stories.

Although this team is a newly established team, most of them have received Scrum training and obtained certification.

The members of the team also actively refer to many books and documents.

As long as the risk is within the company's ability to bear, we are usually willing to let young teams learn from failure, which is far better than telling them directly what to do.

Both good user stories and bad user stories are user stories. The key point is to provide a way for the development team to communicate with users and produce products that meet the needs of users.

I saw their enthusiastic discussions, learning and accumulating experience from their mistakes. I think they will get better and better and stronger. This is the benefit of Scrum.

It seems that we have all been away from this situation for a long time. When we all become professionals, we may have forgotten our courage to collide with the system when we were young and the joy of learning from mistakes.

I think this case has many interesting and worthy considerations.

Does the company need to develop development guidelines and development standards for the Scrum team?

What is the role of an architect?

Can the testing work performed by the Scrum development team replace UAT?

During the sprint, it is found that there may be problems with the user story. What should the team do?

How to write a user story to be called a good user story? Is it enough to meet "INVEST"? In fact, these words are printed on our Story Cards.

...

For the product owner, these user stories are indeed made by real users.

Here we have an important piece of advice for the junior team: never accept solution requirements from the business.

Here we have an important piece of advice for the junior team: never accept solution requirements from the business.

100% agree!

I was once invited to serve as a consultant in one of the best foundries in the world. They want me to assist in the architectural design and usage of click-once deployment.

After watching their presentation, I instinctively asked them why they chose click-once. For their real problems, click-once is not the best solution.

The complexity and failure reasons of many projects often do not come from the problem to be solved, but from the chosen solution.

However, how to judge and choose the best solution requires accumulation of experience.