Much of the writing and learning that you gain about Agile focuses on the day to day nuts and bolts part of execution, however I think that teams are missing a much greater opportunity to improve the quality of both execution and delivery if they spent more time developing their backlog. My teams consistently hear me talk about getting contextually rich user stories as part being able to delivery quickly and with high quality.
In order to get to the point that we have contextually rich user stories teams need to spend some dedicated time building out their product backlog.
Whether you are developing an entirely new product or simply adding features to your existing product, taking the time to fully investigate and build out your User Story backlog is important.
Much is said about doing just enough documentation to get the job done, but what I've seen over the years is that teams that fail to build out user stories that have a specific set of information in them will spend more time trying to figure out what they are doing IN the sprint which negatively impacts quality and the teams velocity.
There is nothing wrong with spending time before a set of sprints building a strong understanding of what the team is going to do.
You wouldn't try to build a house without a certain level of planning ahead of time. Agile teams often arrive at the start of their Sprints with nothing more than a set of ideas. If builders showed up at a job site to start building your home with only a rough idea of what you wanted, they couldn't go very quickly nor would they build something of quality that met your needs and expectations. You might get what you want, but probably not.
Agile teams need to take this approach a bit more, spending time with their Product Managers to not just flush out the features that are wanted, but more importantly the lower level details needed to provide the team an ability to plan more effectively and deliver high quality products.
If a builder shows up and wanted to pour a basement, they need to know more than that. They need to know the size of the basement (ie how much concrete do I need) , if the site has been prepared, has drainage been considered, etc.... Building anything of quality requires planning before you can deliver.
Agile I think too often believes that you can go lite on the planning and still delivery quality. If you think that refactoring is the golden ticket for lack of planning, it's not. Rarely do teams have time to do the amount of refactoring they require to keep their applications clean and scalable. This leads to applications that grow in complexity requiring even more time to add features, all the while thinking that we can go lite on planning.
As you consider Agile as a development process, don't forget that Product Discovery is an important element of delivering high quality product quickly.