1

I'm part of a cross functional dev team, we are applying Agile and also we are trying to adopt UX. Now, we have a difficult moment to estimate the UX user stories. What criteria can be involved to estimate the complexity points? Also I'm interested in listening to other similar experiences (UX Designers that apply Agile).

I will clarify my context ^^:

My team (formed by 4 Dev, 2 QA, 4 Business Analysts, 1 UX Designer) are developing applications that are used internal by employees.

Usually a business request was firstly analysed by the Business Analysts, but now we want to improve the experience of our users and also make research in this scope (here we want to intergrate the UX Designer role).

We want to bring the design process before starting the developing one and this UX activity to be also marked in our backlog.

For example this sprint we created a UX Research user story with the purpose to improve the way that users search for a document inside of one our apps (the tasks that were included in this user story: to create a research plan, run interviews, run usability tests, synthetize data).

The estimation of this user story was made by our "inside feeling", but now we want to define some criteria (for example when we estimate a development user story our criteria are the time, rank of unknown, risks, knowledge level).

Also we can't mark this activity in a "sprint zero" because the journey between research and a tested prorototype can take months in some complex situations.

2
  • 1
    Hi Adelina, what is part of a "UX user story"? If it is about answering a question such as "How would we improve XYZ?", it will be really hard to estimate and maybe you are better of timeboxing it. – Nash Feb 24 at 17:18
  • I think the question is valid regardless of the methodology used to derive the requirements for the features to be designed and developed. I would be good to list some of the criteria that you are currently using or planning to use, so that we can provide more specific feedback as to its validity or our experience with using similar criteria. – Michael Lai Feb 24 at 22:20
2

There are two concepts to apply here. The first is that relative estimation (most commonly done with story points) is not meant to be precise and therefor people get tripped up when they try to overthink it. It's meant to be a gut feel followed by a conversation. One person may say "this feels a little bigger than that 3 point so let's say 5" and then another says "really, I thought it would be a little smaller" and then you discuss why.

The second is that relative estimation that involves the whole team becomes much harder when you split work into disciplines. It is often more helpful to look at UX as a component to everything. Each feature or change impacts the user experience, and so you shouldn't think of UX once, you should consider in each new feature how that impacts UX and what work must be done to maintain the UX in each step and that feeds into the estimation.

0

Apologies about the lengthy answer, because it is a simple question but the complexity of the answer is based on the lack of actual details, so I am trying to cover all aspects of it.

I'm part of a cross functional dev team,

Depending on the number/ratio of designers to developers, and the number of products/services that you are working on, the complexity of the user story can vary because of the methods and processes that you have developed (or will develop) to support these activities. For example, if you have a style guide or design system then generally you will see an upfront effort for creating these 'enablers', but then as the project complexity or tasks scale, you will see the benefits of adopting more efficient practices.

You can read more about the design efficiency curve in this A List Apart article.

enter image description here

we are applying Agile and also we are trying to adopt UX.

Normally when your development team is just starting out on the Agile Software Development journey, you'll find that most of the effort is used up estimating and sharing a common understanding about the process and velocity of the team delivering on the points estimated. Many efforts to incorporate UX design practices into Agile have been written about and explored, but in my experience the best way is to treat design tasks like a programming task (but still try to have your own way of doing things) to help communicate what you are doing clearly to the rest of the team. By that I mean break things down into the same block of defining requirements, design a solution, testing that solution and then address any issues or bugs. But you may find different ways that work better with your team, depending on how familiar they are with user-centred design processes.

Now, we have a difficult moment to estimate the UX user stories.

I think this might have something to do with how you are defining and breaking down the epics and the stories. If you have some examples to share that would be good, but generally you want to make sure that epics and stories are structured consistently if you want to be able to estimate them well. If you think about the fact that all user interactions with the system will ultimately be linked back to components that need to be built (and therefore lines of code that will need to be written), the complexity of the design and how it translates to effort in coding (and testing, etc.) should serve as some guide on a baseline to start from, even if it is just an estimation based on t-shirt size (i.e. S, M, L) or the points system that you use (just make it less precise).

What criteria can be involved to estimate the complexity points?

Based on the previous point I made, if you have something that can be used as a reference of the underlying business logic (e.g. BPMN of business processes), technical architecture (e.g. development framework or design system) or user requirements (e.g. user journey map), you can start using some basic principles to create criteria that can be refined to make better estimates later on.

For example, if you start with a user journey map (e.g. of a specific goal or task the user has to perform) and define that as an epic, then each logical step of the process (e.g. based on the user's mental model) could be defined as a particular story, and then all the tasks and subtasks for that step of the process can be the features that need to be designed and implemented. You could do this with the business process as well, and the difference is that you have to map this to a behaviour that makes sense to the user, the same way that if you start with the user's mental model then you have to map this back to how the business system/logic works. The technical architecture will guide you to the way this is mapped out (e.g. using the elements of the chosen development framework or design system).

So now we get to the answer that you are looking for. What can we used as criteria for estimating the complexity? Here are some suggestions:

  • steps in the business process that has complexity (i.e. dependencies and bottlenecks) potentially requires a more well-thought out solution
  • steps in the user journey that has complexity (i.e. pain points and interactions outside of the system) potentially requires a more elegant design solution
  • designs that has complexity (i.e. the development framework or design system doesn't support it out of the box and is not easily extended) requires more effort
  • areas of the business process or knowledge about the user that is missing introduces more assumptions and validation, and therefore potential risks plus complexity in estimation because of the unknown factors

Also I'm interested in listening to other similar experiences (UX Designers that apply Agile).

I think you'll find that most UX designers don't 'apply' Agile to their design process (at least the ones that I have worked with), and personally I prefer to work in a solution/implementation agnostic way (i.e. don't rely on tools and technology, but have a robust approach to solving problems). I've never had any problems approach the design work in the way that I outlined above to get to a logical and reasonable way of estimating the amount of effort required for the tasks that I am assigned. The constant problem that I see in projects is the lack of a clear and consistent way of communicating the process and applying it within the team. Not to mention the constant lack of time and resources to do the work properly adding to the pressure and stress of the situation.

3
  • I'd be interested to hear more about your experience. I finish my designs (iteratively, including testing and validation) before the team starts the feature in their sprints. So effectively I'm outside the agile process doing 'big design up front'. Wherever I've worked in / with an agile dev team there has been a lack of process for UX, I had to add this myself and is often a struggle to get time and resources. Often businesses don't seem to value UX as much as we believe it should. – Martyn Feb 27 at 8:45
  • @Martyn there is the UX part of the design work as well as the ongoing UI iterations that still needs to be done per sprint in support of developers. I have also heard of the approach taken by the Scaled Agile Framework in what they refer to as the 'architectural runway' (scaledagileframework.com/architectural-runway) used to break up the 'UX architecture' work that is mostly upfront effort (hopefully) and separate it from the research and UI design tasks that are more aligned with individual sprint cycles. – Michael Lai Feb 27 at 11:27
  • @Martyn I have developed my own design language and design system that I adapt to whatever team structure and delivery process is used, and I continually refine this design language and system until there's nothing that can be added or taken away from it. This is what I use in my day to day job as well as personal projects, and it is intended to be agnostic to the way software is being delivered as it is a pure problem solving process, which I am adapting to UX and UI design problems. Happy to go into it but that's outside the scope of this question. Maybe in a chatroom would be more suitable. – Michael Lai Feb 27 at 11:30

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.