Story division in agility

Agile has also been applied for a lot of time. Projects that have been done have been developed from new feature development to SP, maintenance, and various types of projects have all been agile. Each type of story has its own characteristics. Recently, a new team was created. For agility, We only heard the voice to see it. In a plan meeting, the new team's concern on the story Division fully reflects the differences in Agile people's understanding of the process.

The story is very simple. make a report. This report is complex and difficult to complete in a sprint, so it is natural to break it down into small stories. People who lack agile experience will habitually divide the story into the frontend and backend. First of all, this is in principle wrong. The so-called story must be understood from the end user's standpoint. Every time you finish a story, you must improve your business value. Imagine what is the significance of simply finishing the front-end or back-end?

Although we are dealing with a complete report, our po splits it into an iterative and incremental development sequence. For example, the first story is to find out all the data without any filtering conditions or permission control. The opportunity can be understood as the display of what is stored in the database, of course, in the form of reports. The next story will be about adding descriptive columns, adding sorting, grouping, and adding color block tags. I personally think this is a very classic agile story division. However, I scanned the faces of developers at the meeting, and most of them, even those who have been working in agile for more than a year, were quite uncomfortable. They thought why I had to add several descriptive columns for a separate story. In this way, you need to change the interface, storage process, and front-end template every time. This is a waste of time. For a mature scrum master, developers should be able to understand the technical habits of thinking, rather than standing on the user's standpoint. I know what they think, because I have seen a prototype report that has been prepared, and I think it is enough to do it. In fact, this is a very, very contrary to the agile spirit. To be agile, you must think of a word, that is, "change ". This change happens at any time and is encouraging. Never think that the prototype you see must be generated by you. This assumption is not true. Once the entire team has this assumption in its subconscious, it will return to the waterfall model. When thinking about the problem, we must stick to it. After each story is completed, we need po or stakeholders to review it. At that time, all kinds of ideas will come to the fore. When they face a system in their minds, many of their ideas are naive and simple. Once they face a real and available system, their inspiration will go out, this is their job, their professional embodiment, and their pursuit. As a qualified and agile developer, in addition to the quality and speed of each story, it is more important to give yourself the courage to acknowledge and embrace change. In addition, the technology should be able to flexibly use various means to allow the entire project to tolerate and support these changes to a certain extent. This is the core competitiveness of agile developers. We can say it's easy to change the configuration. This is a benign interaction. With such encouragement, market personnel will have more bold ideas, so that the entire product will be more angry and competitive, in order to achieve a win-win situation for the entire team. Imagine that every change made by the demand personnel will be resisted by the technical staff. Even if the company will hold down the development staff to do it, think about anyone else who has nothing to do with it, so is the entire product moving forward based on the developer's idea or the market personnel closer to the user? Is a unilateral victory pale and powerless?

As mentioned above, it is a major principle issue, rather than a specific story. In fact, whether these stories are merged is determined by the entire team. If there is no opinion on development, testing, or documentation, You can merge them, because po does not understand the difficulty of each role's evaluation of the story, it determines that the person in the story is the whole team rather than the person in the story. Ensuring agile democracy and openness is also a major prerequisite.