6

We want to practice proper software engineering for our project and allocate some task to do it. Problem is, I don't know where to put it.

Previously we have epic & user stories like:

  • As a developer, we must observe proper software engineering so that we maintain efficiency

  • As a developer, my code should not be merged to master without passing CI so that code base quality is maintained

A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective.

with this definition I now unsure where to put this kind of items.

Note: Developer = is not an end user role, but the one who develops the software to be used by end-users

Improve this question
4
  • 12
    These aren't tasks that can be "done", in the sense of "complete them and deliver them". This is part of your continuous work ethic. If you need to be reminded of them, something like a sticky note on your monitor seems appropriate. This has nothing really to do with an agile "story". – deceze Jun 7 '17 at 15:38
  • 4
    Avoid putting technical stories on the backlog cause you will delegate decision making to the product owner. Having to explain why prematurely merging to master is costing the business money is usually not productive. (in my experience often the opposite) – Joppe Jun 7 '17 at 16:35
  • How is that first one a story? There's no actionable item, no acceptance criteria, ... Those look more like your definition of done rather than stories. – Bryan Oakley Jun 8 '17 at 12:09
  • the second story seems to be perfect if you want to integrate the cicd pipeline. Although it's not adding business value directly, preventing some bugs proactively is the way I see it. – Manish Rawat Jul 7 '20 at 15:05
5

At the end of the day, agility is about delivering a product to the end user. If putting stories like this help your team get that done, you should do it.

That being said, these are terrible stories. They have no acceptance criteria, they are not something that can be done in a single sprint. What you've written are more traditionally considered part of the definition of done. They are rules that your team has decided to follow in order to help answer the question "is this story done?".

If you want to put technical debt in a story, I personally think that is OK. While you aren't end users of the product you are building, you are indeed users of the tools and practices that you use to deliver the product, and presumably, this technical debt does add some sort of business value (by making you more productive, or making it possible to deliver higher quality software, etc).

Remember: visibility is one of the goals of being agile. If there's work that needs to be done by the team -- regardless of who it is for -- it needs to be visible and accounted for. Just make sure that this work is actually work with valid acceptance criteria and a clear description of the business case for the story.

Improve this answer
1
  • Definitely agree. We tackle dev stories by submitting them to the product owner who then opens the dialogue whether or not we can do a "fix story" in the next sprint. CI and test criterias are definitely part of the definition of done. Get that done by setting metrics (e.g. code coverage). – Yannick Müller Jun 30 '17 at 14:30
21

This should not be a user story of any sort. If you are using Scrum or similar agile methodologies, this would be part of your Definition of Done. This will often have a checklist of aspects that are required for a user story to be consider done such as code reviews, QA, unit tests created, etc.

Ideally, you would automate what aspects that you can so that you don't need to incorporate them into a manual process. For example, continuous integration tests can be triggered when you attempt to commit and if they fail your commit is rejected. There is certainly going to be plenty that can't be automated though. Identifying clear artifacts for their completion e.g. a commit that adds tests, notes from a code review, logs of successful CI tests, can help ensure objectivity and accountability. Ideally, you could capture these things with little or no manual intervention, e.g. notes from a review may be a chat log or comments in a bug/issue tracker.

Improve this answer
2
  • I have failed to mentioned that we have a highly technical PO. He mentioned that he wants the best practices in the industry, quality vs quantity, efficient use of resource (to save money for servers). In that sense, user stories indirectly came from the PO. Anyway, it's our fault in user stories agreement. We will put them to definition of done unless the PO specify this technical stories. Thanks! – letthefireflieslive Jun 8 '17 at 7:43
  • a great idea to formulate the Definition of Done as user story "As a ... i want .. so that ..." so team can see which team roles are affected or benefit from a dod-aspect and why. – k3b Jun 8 '17 at 7:59
3

A definition of desirable behavior, not of the end product but of some production asset, is not considered a story in a Scrum sense. Scrum stories should follow the "what, why, for whom" format. The what should be a concrete, measurable deliverable, not some vague vision.

You could rewrite your first example though:

As the development team we want person X to follow training course Y in order to enable him to perform task Z.

And then some may argue this is neither a product feature nor a user story so it will not be admitted. What happens next is up to your product owner.

Improve this answer
0

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.