Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
We use a scrum-based agile development process. But where should design get incorporated? Separate user stories? Tasks on stories?
We currently think of design as a separate task and break it out as a separate user story with estimated points. The problem I have with this is that the "development user stories" then have these dependencies on other stories which we generally try to avoid.
How should we be incorporating design work in user-stories?
We've struggled with this too. This kinda summarises our journey, that's not to say the same things will apply to you!
Design work is done in sprint
This used to be OK when we were doing long sprints (4 weeks) and there was time for some back and forth, between the designer, UX and Marketing about what the final design should be. Even in long sprints though, if we were doing very different design to what currently existed (i.e. brand redesign), stakeholders would want more time to think than there was in the sprint. I think this approach can work if your sprint length is reasonably long, you're working to strict brand guidelines and your PO can sign off designs themselves without having to go to other stakeholders
As our iterations got shorter and we got burnt by more stories being blocked awaiting design sign off, we tried:
Design as separate stories
This enabled us to bring the work in sooner, allowing us to better plan when we needed to start design work in order to ensure it was signed off in time to work on the story. This has worked OK but it does cause some issues with velocity and estimation (see Lunivore's answer) and I was never keen on having dependent stories in the backlog (design is valueless without the dev, dev cant be done without the design).
We're now doing:
Design is part of our definition of ready
We have a ready for sprint column on our board - stories can only move from the backlog to ready if they are sized appropriately, have acceptance criteria and have completed, signed off designs. This still gives us visibility of forthcoming stories that we need designs for without having 'design for xyz page' separately in the backlog and the design work is done outside of the sprint so it doesn't affect estimation or planning.
That said, we do still have some stories that come through where we end up doing dev to wireframes to get stuff in the right place and end up doing the CSS a week or two later when we've got the actual designs.
There are three reasons for estimation:
They're not really about the size of the work, but more about how much you can fit through your development pipeline.
For this reason, I tend to encourage teams to worry about the development effort, rather than also including analysis, UI design, testing, etc. Development normally forms the most constrained part of the pipeline. There's a lot that developers can do to help analysts and testers, if they become overworked, but unless a team member can code there's not much they can do to help the devs - so I focus purely on development points. Focusing on development points alone is enough to get all these three things.
With regard to working collaboratively rather than having dependencies, I've usually encouraged the analysts and designers to work a sprint ahead of the developers, making sure that enough is done for the developers to have an idea of the scope of the work they're taking on in the planning meeting and estimate it with as much confidence as they can.
I've found it useful to get designers to think of what might be easy to change later - text, colours, placement, etc. - and focus on sketching out a wireframe that devs can use to get the right controls onto a page or screen. They can then work collaboratively, in the later part of the sprint, to get the fine details correct. I've found this also a useful approach with analysis and details like validation, error messages, or with architecture and the actual content of HTML / XML messages, RESTful keywords, etc. Keeping things easy to change later makes the pre-sprint analysis very much more lightweight, and can help teams to collaborate more effectively, regardless of their role.
This is something my team struggles with as well.
And this caused me to ask a different question to my team.
"If you don't know what the design is how can you task out the story and accept it into the iteration"?
As you can guess, this question was greeted with blank looks and stunned silence. We just do was the final answer.
Ultimately I think the best way to handle this question is by having clear and defined coding and design standards that the team adheres to with an almost religious fervor. As the story is reviewed in the backlog via weekly grooming meeting it is updated and a rough design is agreed to based on the teams accepted standards.
If this process is followed your Sprint/iteration planning meetings will go much more smoothly. This should also increase your velocity and lower the number of stories that failed to gain acceptance because they could not be completed due to found work.
If you are talking about Graphics and UI I have always found it helpful to have this effort broken into two or more stories, the first story delivers the functionality without any of the bells or whistles, this gives the design team something to iterate on and come up with a final design in a following iteration.
Ideally all the design elements are extracted into resource files so that they can be updated without having to re-deploy the page.
Jeff
When working with software, I believe design done right is always going on. I look at stories as business/user focused, not development focused. A story like "Get statuses from the database." is development focused and will lead to many problems. A story like "Display the status of the order." is more business/user focused. If you choose to slice up that story into tasks (something I actually do not recommend) then I would slice it up so that each task incorporates all layers of your architecture.
When your team gets used to doing this they will find design considerations early and if your team has good communication (a big key in my book) then design decisions will be discussed at the right time as the discussion will happen dynamically and be unplanned.
I hope this helps.
If you are trying to estimate general UI and architecture at the beginning of the project, consider if you are going to base them on previous projects or not.
If not, I would use separate user stories, and assign a high priority and perhaps risk to them. I would ask myself why previous UI or architecture designs aren’t suitable anymore. This will help you write stories that make sense to the customer.
If you decide that the UI or architecture is going to be similar to previous projects, then a separate story is probably not required.
I think that a good definition of DONE is useful in this case. My team will know that if they mark a user story as DONE, it should be analysed further, designed, implemented, refactored, tested, peer reviewed, and integrated into the build - the story is potentially shippable. Notice design is in there. Their estimates reflect this.
It is also helpful if your team develop software that has a decoupled presentation layer (meaning that the UI is coded separately to the logic). This technique will reduce the dependency between most stories. Perhaps ask your team if this is the case.
Unfortunately, like most things in scrum, there is no right or wrong way. You need to consider many factors and decide what works for you.
We have a "pre project" before the real project starts. In this project the US's are finalized, smart uses caes are created and the wireframes are made.
This way we have a start point for when we start the "real" project. The designer can work on converting wf's to designs, frontend can do there frontend thing and the .Net and SQL developers can do there work. The whole team together in one SCRUM team.
Ofc there is still room for change and improvement in the "real" project
