Could my sprint unit be a scenario instead of a feature? (Gherkin terms)

Question

My team's Business Analyst and I have written some Gherkin files describing user stories of our new project.
As usual, a Gherkin file is composed of one feature, itself detailed through one or multiple scenarios.

The current step is to establish the different sprints (agile evolution) and their respective content.

Personally, I want those sprints to prioritise useful and tangible values for the end user.
That's why I think to consider a scenario as the unit of those sprints.

For instance, we would have:

• Sprint 1 dealing with first and second scenarios of Feature 1 + first from Feature 2.
• Sprint 2 dealing with second from Feature 2 + first from Feature 3.

You get the idea: a feature implementation could not be atomically implemented, but a scenario would.
This would allow to incrementally program several features during a same sprint while letting the possibility to fully complete one feature after N sprints.

I wonder how to handle Jira feeding.
Could one Kanban "ticket" represent an exact scenario of some feature or should it represent the whole feature instead?

Answer 1

First I'd like to say that this is a wonderful experiment. Please chronicle your experience and share it with the world.

We are uncovering better ways of developing software by doing it and helping others do it.

The Manifesto for Agile Software Development

---

Jira doesn't have a concept of features, but it does have Epics. You could enter your features as epics and each scenario as a user story (linked to its parent epic). The concepts map reasonably well and this should give you the traceability you need.

Answer 2

Well, there's JIRA Epics that would fit your features and Stories could be your scenarios. You should play around with using epics, stories and sub-tasks to best suit your needs. I think the method you are describing would be a very good experiment to do - see what happens!