Shulou(Shulou.com)06/03 Report--

Determination of 1.Story

In an agile development team, the product owner needs to put user stories in the queue. This queue is called a product order and is in charge of the product owner.

The product owner decides what to put in and what to take out. The product owner also decides the order-what needs to be built now and what can be done later? This job is not easy to do and needs to be done in collaboration with the team and stakeholders.

two. Determination of Story completed in a Sprint

The product owner needs to work with the team to manage product orders.

Because of resource constraints, there are some issues we always need to discuss-the value, size, priority, division of Story-all of which are often called "order carding". The product owner should sort out the order according to the situation and hold the order comb from time to time. In theory, the whole team will participate, and sometimes some stakeholders, horizontal managers and decision makers will also participate. The agenda of the meeting is constantly changing, sometimes focusing on estimates, sometimes on the division of stories, and sometimes on discussing acceptance criteria.

The product owner knows what to build and shows this to the Scrum team. The team will work with the product owner to determine how much content should be developed in a Sprint.

For software product development, each Scrum role has its own focus:

There should be a healthy relationship between the various Scrum roles. The product owner should pay attention to what should be done correctly in this iteration. The team focuses on how to build these things quickly and correctly. Scrum Master focuses on efficiency, including progress and communication, and maximizes agile fundamentals.

The development team can not only complete the task on time, but also ensure the sustainability of the development. This means that if the team accumulates so-called technical debt (such as unreasonable framework, no writing tests, no continuously improved architectural design), then the team's development speed will become slower and slower over time. This makes later predictions almost impossible. Therefore, given that the team is responsible for maintaining a sustainable pace, product owners should be aware that they should not be pressured to take shortcuts, especially when team developers lack strong development experience. So trust and encouragement are very important. The product owner should be spitting, high-spirited, and dancing, instilling his product Story into the team like a professional liar, making the team fight voluntarily like chicken blood, rather than sighing and transmitting pressure hysterically.

The product owner should avoid saying, "We still have four Sprint left, so you must complete the product order of 1x4 in this Sprint, otherwise you will." . The job of the product owner is to motivate the team with clear and inspiring goals. Team members are most aware of their own development capabilities, so in any iteration, they choose deliverable user stories from product orders, and product managers try to avoid discussing this work, with the help of Scrum Master if necessary.

three. Coordination of product owners among agile groups

Large projects will have multiple teams working at the same time, and of course there will be more than one product owner. So the collaboration between the product owners themselves is very necessary.

In the case of multiple teams, the product owner has an additional important responsibility-communicating with each other between teams! Yes, of course we should keep Story between teams with minimal or no dependencies. But in fact, there will always be some dependencies, whether in terms of product logic or technical implementation! Therefore, there should be some kind of synchronization between product owners so that they can be built sequentially to avoid local optimization and affect the overall efficiency.

The product owner is a vital role and usually requires full-time participation. A product owner can serve as one or two agile teams, but not two or more product owners in one agile team.

four. Demand change

With regard to requirements changes, the product owner will also agree with the team on how to manage requirements changes.

In theory, the Scrum team promises to complete the user story selected from the product order, and as a peer requirement, the product owner promises not to throw out new requirements in the Sprint.

Requirements can be changed (requirements change is the purpose of Scrum and is encouraged), but only outside of Sprint.

However, any product owner with actual agile development experience will feel that this is sometimes a problem, especially when dealing with the business side. There is a better way to solve most of this awkward problem. Don't set the iteration cycle too long when you start to form a team and set up an iteration cycle. Product managers can understand the rules of the business side and advise agile teams to set a more broken and reasonable iteration cycle, such as two weeks or even one week.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.