Trying to transition from Ad-hoc coding to Scrum - what is in a fully refined user story?
I'm a BA/PO. The majority of our devs have been doing ad-hoc coding: talk to the user, code whatever they ask, repeat. The pitfalls are obvious - unable to predict when the product will be releasable in any form, users using the dev team to "try out" design ideas, then discarding them which just wastes time and resources, etc.
I have been trying to convince devs that refined user stories for building a page in an application contain specific information about the fields on that page: Whether the field is optional or required, can hold numbers only or text, max size, etc. I also believe that for displayed fields, the story should say where the field is sourced from or how it is calculated. I believe this info should be in the user story before we start coding - otherwise, how can anyone test it? I'm not asking them to do the refining - I'm happy to do it myself or to work with them.
I get pushback that I'm just trying to make everyone do waterfall, and that I'm wasting time. I don't think I am. Am I crazy? Am I wrong? I've been looking for literature about refining user stories to see if anyone addresses this. All I can find is information about running refinement meetings, when you should refine (2 days prior), putting stories in the correct order, etc. Can anyone point me to some references or authoritative examples of fully refined and ready user stories?
Or at least reassure me that I'm on the right track?
Apparently the forum is not very active anymore 🤔 Here are my two cents.
First: you aren't quite clear on whether your environment is practicing Scrum (or trying to), but since you don't mention Scrum or a Scrum Master, I am going to assume that it isn't. (If it is, then your first stop for guidance should be your Scrum Master.)
You say you are seeing pitfalls and risks. Do your developers and/or stakeholders agree?
In Scrum, refinement is the act of breaking down items on the product backlog into "biteable chunks" for the developers. Who do you think is best suited to decide what the developers need in terms of preparation to deliver the value they are responsible for?
What does your current situation mean for your responsibility to maximize the value delivered by the developers? For your ability to keep your backlog clean, transparent and ordered? For the quality aspect of the product you're accountable for, like maintainability, testability, transferability etc.?
Examples of stories that were refined for the needs of other teams in other organizations in the world may be fun, inspirational even, but the whole point is to grow this in your own organization through employing empiricism and trying out improvements and keeping what works. For this, it is important to explain to each other what you need to perform your role. Challenge each other and build on each other's needs, but respect boundaries and trust.
Hello,
Firstly, the art of refinement isn't explicitly Scrum but can cover many different frameworks - but let me give my opinion after many years of trying to figure it out.
The backlog is an ever-evolving 'story' of the Product goals and how the team plan on achieving them, ever-evolving because we might learn something that changes what we are going to do. Typically a good backlog will have an idea of outcomes (Product goals), outputs (strategy on how we think we can achieve the product goals) and inputs (what is going to be done).
Breaking it down this way, will allow teams to focus on fewer outputs which helps deliver more.
As for User Stories, some teams handle them as mini-outputs written in the format; As a [user persona], I want [output], So that I [justification to why]. E.g. As a Database admin, I would like users to enter their date of birth in a standardised way, so that it meets the data rules. This could lead to a form, but gives the developers freedom in how to do it.
If you write them like this, you can empower the team on how to achieve it but making sure the voice of the customer has been heard.
My preference for refinement is about showing the team the user stories and sparking conversation about it - but ultimately getting the user story to "Ready" (basically, the team could pick up the work and finish it without any expected blockers). A Definition of Ready is a good exercise to run with teams, again not mandated in the Scrum guide.
The definition of ready could include;
- A story is well-written and understood by developers
- A clear Acceptance Criteria
- Developers have estimated the task (see story points or similar)
- There are no outstanding predecessors - nothing stopping it from being worked on
- The developers have shared how they would do it, for complex problems
Refinement is just spending time to get these stories, as a team, to "Ready" prior to Sprint Planning. From my experience, a good refinement session is one that is very conversational, about 1-2 hours a sprint for a two-week sprint works, though you might want more or less dependent on the project stage / team. Doing it gives a slightly further look ahead for the team than just sprint planning and should make planning easier / quicker.
Hope this helps!
I'm jealous! Your developers have the opportunity to work directly with users.
It is all about getting quick feedback.
Imagine you have spent a lot of time 'fully refining' a user story, deciding which fields are mandatory, what formats are required, and so on.
The developers then implement it. When the user is subsequently asked for their opinion, they realise that it's not working.
How much time would have been wasted in this case? Your entire forecast would be out the window!
So, when is a user story 'ready' (fully refined)?
You can keep them lightweight.
It is important that your user story specifies a goal that explains what is to be achieved for the user and why.
The story is 'ready' when two criteria are met:
1. The developers have understood the goal.
2. The developers believe that it can be achieved in one sprint (Otherwise, you should divide the story. Overly ambitious goals are counterproductive.).
One such goal could be: 'As a user, I want to be able to easily update my address so that I can receive letters from the company.'
The 'why' is that users want to receive letters.
The 'what' is that they want to be able to update their address.
The user story is not concerned with how this is done (e.g. which fields are necessary). It is the developers' task to decide how to manage this using their experience. If they need more information, they can ask. Usually, the user knows best.
Imagine:
In Germany, postcodes are five digits long, so the developer uses this data format based on their knowledge. If a user then says, 'But we have colleagues who live in the Netherlands,' the developer can correct it immediately.
However (and this may address your concern):
They must not add any special features that are not necessary for the goal.
For example, if a user requests that their postcode be checked against their address and this cannot be done in the current sprint, the developer should not attempt to do so. This is not necessary to achieve the above goal. (However, in this example, it would be useful information for the Product Owner for future optimisation.)
You should be able to rely on goals being achieved in the sprint.
Conclusion:
- Keep the user stories lightweight.
- If your developers work with the user to achieve the goal, that's fine.
- However, if they allow themselves to be persuaded to incorporate extra requests that are not necessary for achieving the goal, and therefore fail to do so during the sprint: this must be discussed.
Hope that's a base for discussing with your developers