Get your Bloody User Story done

Early in my career, I remember the top management saying: let’s try to be more agile. And what we understood on Agile back then si deliver in small cycles or waves.

So we the team we were trying to set goals for two weeks and see what we can deliver. It was amazing. We were doing testing earlier, but we weren’t released earlier, and the shit hit the fan aways.

So what did we say: the Agile is nice, but it doesn’t always work. Let’s go back to the waterfall; we are just more careful, we learned more, do better management, closer, it’s going to work. Project management exists since the ’70s. It’s working.

Now, a decade later, I know Agile works, if done the right way. Getting the user stories done is the foundation of the whole thing.

What is a user story?

In Agile, user stories represent the description of a feature that delivers value to a customer.

As a < ACTOR>, I want < GOAL > so that < BENEFIT >.

The user stories must provide value to the customer, which in most of the times, it means development at all the layers. Like the cake. The users will not eat the base, fruits, decoration, but everything together.

Most of you reading this article might already know about it. But while it is so knowledgeable, it’s indeed the hardest thing to do in Agile.

You can read more about How to split user stories here or about the Hamburger Method to split user stories from the development team perspective.

Definition of done

In Agile Software Development, each scrum team has a Definition Of Done for the User Stories to ensure the quality of work and to assess whether the scrum team completes a User Story or not.

You can read more examples of DOD here: User Story Definition of Done in Agile Software Development and the technical debt.

Why is DOD so important?

The Definition Of Done in Agile is a measurement of work completion. Growing incomplete work is a dangerous habit. We have the feeling is just a few left, but in reality, we need to look at the big picture: we left the user story, the code, the testing, the branch. We need to go inside, to look on the code, to debug, to remember what we did, to understand what someone else did. And this assuming is indeed not a big thing. That’s a lot of money spent isn’t it?

The work nearly done but not done might have a brutal impact on the planning. In a lot of cases, “polishing” really finishing a user story is what takes almost as much as development.

It adds up technical debt, pressure on the team, conflicts inside the scrum team, increases management from the scrum master, and micromanagement from the administration. All these are the consequences of not finishing the user story. All these are reasons why Agile has been so widely adopted lately.

DOD I care about

• Product Owner acceptance. It will mean that the product owner is comfortable to demonstrate the work done to the stakeholders during the sprint review.
• Deployment to prod. We make the difference between deployment to Production Environment and release on demand.
• Code quality — that is up to the standards set by the team or by the organization
• Automated integration testing — this is a long story. There is

How Agile works?

The power of Agile is that what you hold is what you have. In the user story development, we include everything needed for the functionality to be used by the final user. When the user story is marked as done, the team doesn’t touch it anymore.

Very simple to say but extremely hard to do it. We tend to build more and then test at ones. We think we are more efficient. Are we?

I don’t know. But what I know is the terrible feeling of the boom that projects have just before going live, that there is never enough preparation, we are always wrong; there are still specs missing.

Below the arguments I often hear when I speak to the teams I coach:

BUT this is the theory. Real-life doesn’t work like in books. Below a list of the main arguments, I hear from my clients and the solutions I work with them to implement.

BUT we cannot deploy to prod. Why not? The most real reason is that there is not a continuous deployment pipeline set in place. DevOps is a critical function you need in your teams and company. As your organization hires agile coaches, you can hire a good DevOps that will build the pipeline your team needs to. The alternative is to coach the teams to do it. I’ve seen a lot of patches on this topic. And as long as there is no up to date technological upgrade, your teams will always be held back.

BUT we cannot test now. Why not? My clients will tell me reasons like lack of data, people’s availability, dependencies. But the reality is that we are applying agile methods in a waterfall way. Agile development needs to be driven by value. The functionalities developed must be the ones that bring the highest return of investment and not by hierarchy structures, comfort, popularity, people skills. Agility is about delivering value now, about being where the market is, about adaptation.

BUT the PO has other duties than the Product Owner for a team. The reality is that I haven’t seen many organizations that have one dedicated PO for only one tribe. What I always say to the teams I work with is that we should find a way to release the weight of the Product Owner. In essence, the team can write the user stories, and the PO reviews them, there are peer reviews of the user stories to catch the significant issues, there is automation testing that tests all the scenarios. There are many solutions that each scrum team can find.

BUT we only have few things to do, is nothing. It might be that indeed there is almost nothing left. But if it’s the case, why not doing it during the sprint, so it’s done. Polishing work might take more than

BUT our velocity will do down. No, as a team, you will know your real speed of the functionalities that can be used by the final user. Read about how do we manage bugs in agile, the fake velocity created by double counting of the story points when we leave the user stories incomplete.

BUT automate everything takes a lot of time. So does the regression testing. On this one, I’m with you — the team and the organization must find the right balance between the effort put in developing and maintaining the automation testing vs. the benefits.

BUT my value is when everything is done. Not in Agile. In agile, The Product Owner must build the product backlog in slides of functionalities and prioritize the highest value is at the beginning of the development. The core functionalities that bring 80% of the benefits are high on the product backlog.

BUT as a Product Owner, I cannot release a product that is complete. There is a difference between deployment to the production environment and releasing a product. The functionalities might ready, but they might not be available for the users. There is a technical concept called toggle for each feature. In that way, the Product Owner decides when to activate the functionalities for the users — toggle on. What is essential for any organization is to know the features delivered and have control over the decision of launch.

In conclusion, if you want to stop blowing up budgets, estimations, get the user stories done! It is not easy. That is the real challenge of Agile. That is what makes it work, and that is why it is so hard to master it.