User Stories that Don’t Kill Creativity and Collaboration

What is fascinating about the User Story is that it’s an open-ended framework that can be used well or it can be used poorly. The most important thing is keeping the User Story in problem space and to link it back to your value proposition and problem scenarios. Two reasons for that:

  • It helps to debug when something goes wrong by tracking back to the origins of the story and what problem it meant to address
  • It facilitates the important discussion with the team so they can reach a shared understanding of what the problem is and together conclude what is the best way to solve it

Continue reading

Stories or Tasks on Kanban Sprint Board?

I often get asked by Agile teams what should go on a Kanban board during sprint planning. The short answer is: It depends on what works well for you as long as you are maintaining the spirit of the methodology by keeping everything visible on the board and “Just-in-time”.

Some companies focus on recruiting highly qualified full stack developers that can work on different areas such as database design, business logic, front end, testing, integration.. etc. In this case, I believe the best option is to use only user stories on the Sprint board. Each developer will be able to handle a full user story and move it across the Kanban board as a one coherent unit which reduces the overhead of handoffs and coordination with other developers. Also it makes easier for the product owner to verify a full user story rather than trying to combine multiple tasks together to create a testable narrative. Continue reading