SCRUM backlog/sprint backlog per project

[jxsl13]

I would love to see people participate in this issue as much as possible and collect a lot of suggestions and ideas.
I would find it quite interesting to have features like Miscrosoft's VSTS (https://www.visualstudio.com/team-services/).
Not necessarily exactly like those, but something befitting the agile process model SCRUM.
:) Have fun discussing.

[jonasfranz]

Could you please point out which features do you especially want?

[jxsl13]

In SCRUM you have basically one Product-Backlog, containing User Stories, which are sorted by priority or by some predefined value.
Every User Story consists of most likely a title, description and maybe a name for the value to measure the priority in(more or less like "issues", but sorted by priority) as well as that priority field.
Also a field, which could indicate, whether the User-Story was implemented, removed(because of some issues, not finished or needs more description)

In every Sprint(defined period of time) the devs take some User stories from the Product-Backlog and add them to their Sprint-Backlog, which other than the P-Backlog also consists of (maybe optional) ideas how the developers want to solve the specific problem, which is described by their chosen User-Story. Every developer can see every other developer's assigned user story, but can not edit it (maybe only comment on it)
Devs should be able to only modify their own solution notes, but not the description/title of the user story, thus the need of at least two roles (product owner and developer(not exclusive))
Has dev-1 finished his assigned user stories, he could ask another dev-2 to assign his (other dev-2)user story to dev-1 (well, open for discussions at this point).

Is the sprint finished, meaning the time's up, there could be some kind of overview of the finished user stories and also unfinished ones.
These user stories need to go through two phases.
The finished ones need to go through both phases, one is the Sprint review (e.g. showing the customer the finished improvements)(only finished user stories).
The second phase would be the Sprint retrospective, where the dev team takes a look at what was finished and especially, what was good in the process, and also which user stories were not finished and why not(moving them to the product backlog)
(Maybe some "bulletin board" with information about the definition of "Done", meaning when to consider a user story as done and some process optimization stuff)

Some functionality to kick off a new sprint and maybe based on the normal issue system, the product owner could take these suggestions and convert them into User stories, adding priority, more detailed description etc.

I don't know what would be better, to use the existing issue system and use it as input for the product owner to take from or to use the scrum stuff exclusively, excluding the normal issue system and see the scrum stuff as an own issue system.

TLDR :D
In general there need to be two roles, one being product owner(by default project owner with the possibility to change roles by the first product/project owner) and the other being developers.
Moreover a Sprint is needed, which has a defined(product owner?) duration and some mechanism to kick off a sprint. Kicking off a sprint makes no sense if there is nothing in the sprint backlog, thus the need of a sprint backlog containing assigned(?)(maybe everyone of the devs can change assignments) user stories, which cannot be changed, but commented on(one sticky comment with sub comments?).
Every developer needs to be able(only within a sprint? or whenever he/she pleases?) to change the status of a user story from unfinished to finished (question is, what kind of states can a user story have?)
When the sprint comes to the end, the state of the "issue tracker" should change its state to review phase, only showing finished user stories(And only the sticky developer comment? no comments? all comments?). (What states should we need? : suggestion: planning, sprint, review, retrospective)
Then the product owner(?) should be able to change the state to the retrospective, where maybe the "bulletin board" with suggestions, patterns, good practices, bad practices, etc. as well as well as all, finished and unfinished user stories should be visible again.
After this phase the product owner(?) should be able to change the phase to the next one, planning, where unfinished user stories should(?) go back to the product backlog and finished user stories either archived or deleted(in order not to point fingers at people, when a bug is found afterwards).
And in the planning phase the dev team can can add the user stories again to their sprint backlog.
And after this step somehow a sprint needs to be kicked off, maybe by the product owner.

Have fun discussing(I hope)

[jxsl13]

User stories could also have all the properties an issue in the normal issue tracker has, e.g. tags and so on.

[thehowl]

This was already discussed in #805. Personally, I think that workflow of teams may greatly differ, and for this reason we should not have any "projects" feature similar to GitHub's or GitLab's, or the Scrum system of Bitbucket. I don't think there's any viable one-size-fits-all, but Issues are a good compromise for small projects where one can expect not to have a huge amount of things to keep track of.

Gitea unto itself should, as far as I'm concerned, stick to GitHub/Lab-style issues and only provide tools to deal with them using APIs and webhooks, or allow people to use external issue trackers (something we already have!).

[sapk]

@jxsl13 I can recommend you https://github.com/opf/openproject that can work along Gitea. It support multiple workflow and you can setup gitea to use it as your ticket/issue manager (by setting the url in gitea)

[jxsl13]

@sapk thanks, looks quite promising

[Caballerog]

@sapk I've installed open-project and change the ticket/issue manager at Gitea but I've a question, is there any relation between open-project and gitea? or only Gitea link to OpenProject?

My question is because I don't know if there is any way to relation my gitea issues with openproject task (the code of gitea, the same number of issue in gitea and openproject).

Thanks for your reply!

[sapk]

It maybe possible to link more tightly between openproject and gitea via api but I don't know anyone that as done it (and maybe require some ajustement to gitea or openproject code).
I use it mostly to do advanced project management aside from code hosted in gitea.

[exside]

I do like the Gitlab approach of allowing to create scrum/kanban "boards" out of labels and turn them into a different view...nothing really changes, it's just a different view, but a very useful one IMHO.

[rudineirk]

For some teams having an integrated board on the same tool were the issues are created is a must. It would be really useful to have boards like Gitlab or Github has. I was thinkering with the idea of a gitea integrated board/projects tab, and I created a prototype of the idea, it's based on the Gitlab approach:

It's not really working, it's just fixed data, but I think the visual should be something similar to this. The code is here:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Something that is missing is the visual to create/select boards, like Gitlab has. It would be really useful to be able to create boards for multiple teams.

[rakshith-ravi]

@rudineirk Were you able to work on this?

[tinxx]

I would like to see this happen, too! It would enable many small teams to directly and primarily work with gitea instead of struggling with external and possibly hard to set up tools like Taiga.io, etc.
With external tools things like linking commits to issues etc. is likely not possible, that's a huge bonus of this approach! (Being able to just mention the issue ID in your commit to make it appear in the issue/ticket is pretty cool :)

[ssbarnea]

I am really interested about this feature as our team is currently using https://taiga.io/ but the real value is to have an inregrated issue tracker with kanban/scrum planning functionality.

I think that there is a lot of things to learn from GitHub implementation which originally started exactly like gitea. Their implementation is generic enough to allow users to use it for both scrums and kanbans even it it has no idea what a sprint is. If people can define columns and drag and drop cards they will likely find a way to do the planning with it.