I'm looking into using user stories for our next web project. For example:
There will be a homepage with some information and the latest projects for the client.
How could you turn this into one user story? And it has to be designed by a designer, then developed...But if this is only one card how can we track this on the board so we can tell if the designer currently designing it or if someone is developing it?
User stories are written from the point of view of the end user. An example user story might be something like:
As a website user I would like to see important information on the homepage so that I find this site useful
The types of information you show could be further detailed in the acceptance criteria for the story. These acceptance criteria would come out of a discussion with your Product Owner or Stakeholders.
The task board tracks exactly the kind of information you mention. For example, you could have the following columns on your task board:
Each card will represent a story and the column it is in will indicate who is working on it.
You can't manage or track epics like you have described in a meaningful way. In addition, user stories that lack context and a clearly-defined value consumer aren't generally useful for project management, or even as conversational placeholders for business communication.
There will be a homepage with some information and the latest projects for the client.
This isn't even an epic. In addition to not following INVEST criteria, an epic this big doesn't even convey useful information about the themes and stories that might be packaged under it.
How could you turn this into one user story?
The short answer is:
User stories should be much more granular than what you've described in your original post. When stories are small enough, and have clearly defined tasks associated with them, then it becomes possible to track the stories through your swimlanes or status columns.
But if this is only one card how can we track this on the board so we can tell if the designer currently designing it or if someone is developing it?
If the stories are decomposed into tasks, then the story can get passed from function to function in a clearly-definend way. However, this is not an agile approach. Rather than separating design from development, user stories should represent a vertical slice of value through both functions and the team members should work on them collectively and collaboratively.
Your kanban board will then reflect the state of each story, or its location in your process pipeline, rather than who is working on what. While those types of details can be attached to user stories, doing so is often a "project smell" that the team is still following a waterfall-based, upfront-design process.
There is a lot of information out on the web and in books about how to create meaningful user stories, and how to manage and track them. Answers here cannot provide a canonical list of resources that a practitioner should know, but you can certainly start with some classics like:
Please don't expect answers on a Q&A site to substitute for baseline knowledge of user stories. Truly understanding user stories, how to apply them, and how to manage them within your project management process is a complex topic.
