2

I am currently working as product owner in a firm where we follow agile methodology. I would like to discuss about a scenario faced in my daily work life.

We have started working on a project to implement a new report in our product. I proposed a design and shared it with the UI team. Then I started writing user stories based on my proposed design. The proposed UI design was finalized by the chief product officer. But during the product refinement meeting, the Development team suggested a totally different UI design. This creates extra work to update the stories based on that design.

So my questions are

  1. What is the best time to start writing stories?
  2. Should we finalize the UI design first instead of writing stories?
  3. Is it fine to start working on stories after finalizing the UI design?
  4. Is there any suggestion which can be followed to avoid similar issues in the future?
2

During refinement you discovered another design and went with that one instead of what you thought originally. It happens. That's what refinement is for. To add details to the backlog items, acceptance criteria, estimates, priorities, etc. If you discover better ways to add value to the product, or conditions change, or you get new insight into what youare building, then the user stories can of cource suffer changes. The product backlog is not fixed and is never complete.

This creates an extra work to update the stories based on that design.

It's not clear from your question, but by any chance did you create very detailed user stories based on the original design? You need to update the user stories based on the new designs, but how much is this "extra work"?

User stories should be short. It's "what" needs to be done. User stories are not software specifications where you detail the "how". If you decided on a new design, that normally shoudn't affect the "what". The "what" is the same even if the UI is different.

Now to your questions.

  1. What is the best time to start writing stories ?

There is no best time. All the time. Whenever needed. They are a way to organize the work you need to do, track it, take decisions about, discuss with others, show the result after they are implemented, etc. So whenever you know what you need, you can start writing the user stories. You can add details later. The stories at the top of the backlog are detailed enough to be able to do the work, but as you go down, stories become less detailed to the point they are just a placeholder to have a conversation about them and detail them when their turn comes to be implemented.

  1. Should we finalize the UI design first instead of writing stories ?

Depends on how much the design affects what you need to build. Do you need all of it to be finished before doing anything? Are there parts that are already known? Finalizing the design and writing stories are not necessarily exclusive to each other. Like I said, the product backlog evolves all the time. You might write some user stories now, some later, some are important now, some will become important later, some user stories will be more detailed, some less, etc.

  1. Is it fine to start working on stories after finalizing the UI design ?

You should have an idea of what needs to be done even if the UI design isn't finished. During refinement and sprint planning you will discuss details of how to implement each story. For that it's best to have the design finished so you don't come back and change your implementation if you get a new design. In Agile that won't be a problem, things change all the time. But it will be inneficient. It's better to have the design finished before starting work on implementation.

  1. Is there any suggestion which can be followed to avoid the similar issues in future ?

Collaboration and communication.

How do you as the PM interact with the development team? Do you give them work to do or are you all a team working on the same goals but with different roles and responsabiities? Giving people work has delays as one needs to define the work to be done then present them to who needs to do it, they give feedback, you make changes, then repeat. When you increase collaboration and communication these things still happen but the delays get reduced.

1

What is the best time to start writing stories ? You should have a product backlog of all the features, and refine the prioritized stories sufficiently before every sprint.

Should we finalize the UI design first instead of writing stories ? It goes hand-in-hand, hi-level design + hi-level features, detailed finalized design-> detailed stories.

Is it fine to start working on stories after finalizing the UI design? You should refine the stories after finalizing the UI design. But the stories should already exist.

Is there any suggestion which can be followed to avoid the similar issues in future. Discuss your issue with the scrum master or PM, let him help with the coordination. The main issue I see is the lack of communication and agreement of process.

1

A UI design can't be considered "final" before the users have seen it in action and tested it. If you are in the early stages of something that doesn't yet exist then I suggest you only write the minimum number of stories and least amount of detail you need for the next iteration. For later iterations you can have placeholder epics if you need them for planning purposes: big in size and minimum amount of detail.

Things may change radically once people see the UI but you can always create new stories during future backlog refinements.

1

What you are describing is expected behavior, not something unusual that needs to be fixed.

As you work on the UI you will think of functionality that now need stories, and while writing the stories you will think of use cases that now need to be incorporated into the UI.

So, to answer your questions in reverse order:

  1. Is there any suggestion which can be followed to avoid similar issues in future?

No - this is the correct way to work.

  1. Is it fine to start working on stories after finalizing the UI design?

No - how can you finalize the design before you're sure what the stories are?

  1. Should we finalize the UI design first instead of writing stories?

No - how can you finalize the UI before you know what the stories will be? The initial UI needs to be with intention of it being throwaway so that nobody becomes emotionally attached to it and makes life difficult by preventing it being changed.

  1. What is the best time to start writing stories?

As soon as you have a draft UI, you start writing stories, then refine the UI to match the developing stories, and add stories that become apparent while refining the UI. Continue this iterative process and eventually you will have covered all expected stories that you want in the upcoming release/iteration and have a matching UI.

2
  • 1
    The only thing I would question is your use of the word "release" in the final sentence. "Upcoming iteration" might be better. If the next release is expected to be, say, three sprints away and if the users haven't yet tested the UI then the PO may decide on something very different once they see the output of sprint 1. Writing a comprehensive set of stories for the next release could therefore be wasted effort. – nvogel Jan 18 at 9:21
  • @nvogel - good point. Fixed. – Danny Schoemann Jan 18 at 13:30
0

In my experience, You and your UI team should come up with the first version design including the project core features,

Cause each core features may related to each other and may effect each other in design point of view.

After you have this design, You can visual this project to your development team and show them, This is what we're going to do and reasons behind those design decision. Also at this point you can start writing the backlog, BUT the backlog should be value oriented not design oriented, and backlog should go more into level of details that's very clear for developers to start deving.

So yes actually design should be finalize before story go into the development, But this is not always. For example proving an idea that's cant be finished by UI designer.

For dev team that suggest you the totally different design, You should find the reason behind that suggestion.

If dev suggestion trying to tell you that your current design make no-sense for the user, This is totally make sense for dev to suggest. And if it's true. You need to improve your design and product visions then.

If dev trying to suggest a ways that's easier to dev but give the same value to the user, This is still make sense, That's also part of your jobs to notice, ask for people opinions and refine the design before you start writing the backlog.

But if your dev suggestion is just to avoid work efforts and also effect the user by having the negative user experiences, This is the point you need to consider that you may not accept this suggestion.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.