STORY POINT LÀ GÌ

Good estimation helps sản phẩm owners optimize for efficiency and impact. That's why it's so important.

Bạn đang xem: Story point là gì


*
By Dan Radigan

Estimation is hard. For software developers, it"s aao ước the most difficult — if not the most difficult — aspects of the job. It must take inkhổng lồ trương mục a slew of factors that help hàng hóa owners make decisions that affect the entire team — và the business. With all that at stake, it"s no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that"s a mistake. Agile estimation is just that: an estimate. Not a blood-oath. 


There"s no requirement to work weekends in order to compensate for under-estimating a piece of work. That said, let"s look at some ways lớn make agile estimates as accurate as possible.


In agile development, the product owner is tasked with prioritizing the backlog — the ordered các mục of work that contains short descriptions of all desired features and fixes for a sản phẩm. Product owners capture requirements from the business, but they don’t always understvà the details of implementation. So good estimation can give sầu the product owner new insight into the màn chơi of effort for each work thành tựu, which then feeds bachồng into their assessment of each item"s relative priority.

Xem thêm: Thành Ngữ Liên Quan Đến Anger Là Gì ? Nghĩa Của Từ Anger Trong Tiếng Việt


When the engineering team begins its estimation process, questions usually arise about requirements and user stories. And that"s good: those questions help the entire team understand the work more fully. For hàng hóa owners specifically, breaking down work items inkhổng lồ granular pieces và estimates via story points helps them prioritize all (and potentially hidden!) areas of work. And once they have estimates from the dev team, it"s not uncomtháng for a sản phẩm owner to reorder items on the backlog. 


Involving everyone (developers, designers, testers, deployers... everyone) on the team is key. Each team member brings a different perspective on the sản phẩm và the work required to deliver a user story. For example, if sản phẩm management wants to bởi vì something that seems simple, like tư vấn a new web browser, development và QA need to lớn weigh in because their experience has taught them what dragons may be lurking beneath the surface.

Likewise, kiến thiết changes require not only the thiết kế team"s đầu vào, but that of development & QA as well. Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don"t feel included, và compromises the chất lượng of the software.