6

I'm in the early stages of developing a new project and I'm trying to pick up and apply agile techniques. In particular I'm trying to set up a Kanban approach with the development of this project.

For my last project I familiarised myself with Atlassian Confluence and it was a pretty immense help, so I've purchased a license for Jira and Jira Agile to go along with it.

Last week I held a meeting with some other members of our company who are the de facto customers of this project since it will be used internally. I discussed all the requirements they had and turned them into a set of user stories. Here are a couple of examples:

  • As a developer*, I want to be able to create a test procedure which gives me control and monitoring of the motors in the test rig.
  • As an operator, I want to be able to see the reports of tests that I run.

These user stories have been recorded in a Product Requirements page in Confluence and transferred over to a Kanban board in Jira. My board currently looks like this:

My problem is that these user stories are providing high-level descriptions for the core goals of the project. As soon as I start doing any work, I'll have automatically made progress in all of them and so I'd have to move all of them into "In Progress". And none of these user stories would be marked as done until I'm nearly complete with the project during which time they would all get marked as done in pretty quick succession.

It would be a lot more intuitive to me if each card on the board represented a small, simple task that was along the lines of "Implement this small piece of functionality" or "Investigate if this approach is feasible" - something I can assign to myself or someone else and expect it to get done within a few hours or days. How does an approach like that fit in with the idea of using user stories on a Kanban approach?

One thing I could do is create a series of sub-tasks for each story. The problem with this approach for me is that a lot of these tasks would be shared as a common requirement between most if not all of the user stories.

In brief, I've created a set of user stories and not sure what to do next. Have I made a mistake in creating these user stories or am I just not seeing the next step?

Edit

*by "developer" I meant "test sequence developer" i.e. one type of customer of the product.

4

Creation of a backlog and user stories was definitely a good first step but...

Your user stories should not be interdependent. As you describe above, you feel as if you would have to move all stories to in progress, if you started any specific one. This indicates that you have epics or stories that are not vertical slices of business value. I'd recommend looking at what you have and trying to re-write it in such a fashion that each story is independent, relatively small, and delivers a piece of value to your customers when completed.

If you find yourself writing a story that starts with "As a developer..." stop and think about what value that provides to the customer. Try and write all your stories with a customer actor in mind.

Kanban is a lot harder to follow than Scrum. Consider why you have chosen Kanban. Many teams use Kanban when they are unable to get a full iterations worth of backlogs defined because requirements change so rapidly.

I also wanted to add some thoughts on the actual Kanban board. A key concept of Kanban is visualizing your workflow. Your current board looks out of the box. Many Kanban teams will customize their Kanban flow to be more granular. For instance a team that has defined QA and Dev roles along with a UAT environment may have a flow that looks like Future>Defined>Developing>Testing>UAT>Production. Think and discuss with your team what their workflow looks like and make the board match it. In the long-run this will position you to focus on key Kanban concepts like cycle and or lead time as well as WIP limits.

  • Thanks for the response. I'll mull this over and post a more detailed response later but just to clear up something first: "I'd recommend looking at what you have and trying to re-write it in such a fashion that each story is independent, relatively small, and delivers a small piece of value to your customers when completed." Absolutely, but to be clear I'm talking about test sequence developers here - not software developers - who actually are one type of 'customer' of this project. :) – Tagc Jul 14 '15 at 18:46
  • I've given your answer more thought. My response is a bit long to fit into a comment so I hope it's not a problem if I link to it on Pastebin instead. pastebin.com/dPmMKJFP – Tagc Jul 15 '15 at 8:15
  • Finally had a chance to read your pastebin. Thank you for the feedback. I'd still caution that while Kanban is simpler at a surface level to implement, when you delve into team maturity, discipline, and the human side of running a kanban team you will realize that it is much harder to do than a pure scrum implementation. – WBW Aug 5 '15 at 21:32
1

you could create subtasks for each of those user stories you have, as you suggested. Personally, I'd take it a level up. Change the user stories you have to EPICS - and then create what would have been subtasks, as stories associated to the epic.

Yes you may have similar tasks/stories which are duplicated; but perhaps the acceptance criteria may be different, depending on the story? By elevating these up a level so that you utilise EPIC as the container for all your stories; your story can be more fine-grained; plus you have the added advantage of using sub-tasks. Aim to have a story only be the equivalent of 2-3 days (max) worth of work (if it's bigger, split it into smaller stories); and aim to have tasks be 0.5 day to 1.5 days worth.

You can colour code your story cards to reflect which EPIC in belongs to in JIRA.

Good luck - there's lots there with JIRA - with numerous plug-in. Over time you can get more fanciful - but for starters, just track the stories/task - ensure you have WIP set; and monitor the flow of work.

  • Thanks for the response, Steve. "Change the user stories you have to EPICS - and then create what would have been subtasks, as stories associated to the epic." I have a concern about this: the subtasks I have would be things like "Create this class" or "Implement this functionality". Those don't seem like they'd constitute actual stories. – Tagc Jul 16 '15 at 7:16
  • Ahh yes - those do indeed sound more appropriate as task and not stories – AgileSteve Jul 16 '15 at 11:22

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.