Article Series: Better Estimations in Scrum — Part 3: The Business View

Previously in our article series, we discussed how to measure and estimate stories. Having a good story is a main priority though when we are both measuring and estimating stories, right?

In this article we will discuss in detail two commonly used acronyms that help Product Owners write great Stories.

At White Prompt, our solutions in the software development life cycle go beyond code. We apply our deep bench of experience and knowledge of the infinite possibilities of tech to solve challenges; we set the strategy, stick to the process, and dive into the development. If you are interested in developing an exceptional project with our team, contact us today or head to our website to check out our case studies to see our solutions we provide for our clients.

The three Cs

Ron Jeffries, one of the founders of the eXtreme Programming movement, suggested that for developing the full potential of a story the three C’s should happen. They are: Card, Conversation and Confirmation. Let’s discuss what the three C’s mean in further detail for your team.

Card

Cards can be post-it notes, electronic cards in a system like Jira or ADO, or any other format you may prefer.

Remember that the cards should contain the user’s needs and should serve as a placeholder for Team conversation before committing to do the work.

Unlike Waterfall business requirements that have to be fully detailed on day one, cards can evolve as the project progresses. In Agile, the cards that are higher in priority are the cards that should be discussed thoroughly and contain enough detail to be started by the Team in the next iteration.

Another benefit of cards is that they can be changed or discarded as the Team progresses and becomes more efficient, and new ones can appear as the product evolves and POs receive feedback from users.

Conversation

Cards are placeholders for something that should be delivered, and may include other elements such as initial user research, design work, or brainstorming notes.

In the context of Agile, we could think of a Conversation as a synonym of Collaboration. User Stories are called stories because we should be telling them to each other and discussing the details within our teams.

As the Team begins to work on user stories, they should discuss the story thoroughly to come to an understanding of the user’s needs.

Refinements are instances where the Team and POs can have conversations about the selected stories. These stories being discussed are selected by the POs based on prioritization.

Confirmation

The gatekeeper in this instance is the PO, who should review the story after it has been tested to see if it has been completed.

This concept of confirmation prevents incomplete work from escaping the development phase and includes any Acceptance Criteria established and agreed upon for the story.

Aside from the Acceptance Criteria, the story should comply with the project’s Definition of Done. For more information about DOD you can check this article.

INVEST

INVEST is a mnemotechnic rule that POs should run through when writing stories.

Here’s a detailed description of each of the letters that form the acronym.

• Independent: The Team should be able to get it done during the sprint without having to depend on any other user Stories. This is something to take into account at the moment of prioritization. For example, imagine that story A provides huge value to the user, but it’s dependent on story B which doesn’t provide much value. It is a common mistake to prioritize A over B based on value without taking any dependencies into consideration.
• Negotiable: Unlike traditional business requirement documents that are often considered contracts, Stories are open and “unlocked”. They should start an ongoing conversation between the Team and POs as the refinement, and even the development, processes are happening. The Team should really feel free to question the requirements if new information arises, and the product team should be able to revise the Story if new information from business arises as well.
• Valuable: The User Story should bring some concrete value to the user or at least be part of a business goal. The WHY section of the story should be clear and understood by everyone.
• Estimable: At the beginning of the sprint the team should understand the story well enough to be able to estimate its complexity and the effort required to deliver the story as a potentially shippable product.
• Small: The story should be small enough for the team members to finish in the Sprint. If not, the story can be separated in a way that makes sense and adds value to the user.
• Testable: Whenever the stories are ready, they should be able to go through thorough testing.

Conclusion

Agile is different than Waterfall in the requirements aspect. In Waterfall, requirements are written in stone with little to no collaboration between developers. In Agile, good POs should work together with the Team to make great stories that can lead to great estimations.

We think and we do!

Working with us at White Prompt can lead to great outcomes for your project or application. Do you have a business that requires an efficient and powerful data architecture to succeed? Looking for a software development agency to make it happen? Get in touch with us at White Prompt today!