14

TL;DR Titles should be short and pithy, but meaningful. Think of them as communications shorthand that give the team a handle to refer to, not as lengthy descriptors. The story labels should make it easy to differentiate stories from one another. Effective Story Titles What constitutes a good or bad title will vary a lot based on your organization and ...


9

TL;DR You have an X/Y problem created by skipping over analysis of the process problem in favor of a tools-based approach. JIRA and GitHub Issues are tools, not processes, so until you fully define your process flow you will remain at disadvantage. You need to define what you are tracking, why you are tracking it, and how you will use the tracking data to ...


4

It doesn't really matter. Just do what seems suitable for your processes. In my experience, if you are using an electronic board, the "As a user I want" phrase will be too long to be shown directly on the board and get truncated to a meaningless "As a user I want to..." (or slightly longer, but not long enough to really tell what the stories are about). In ...


4

TL;DR You're conflating engineering and architectural domains (and especially source code management tooling) with business and project management concerns. There's no direct mapping between product increments and merge requests, especially in large or complex systems. Think of a vertical slice as the thinnest piece of coherent, full-stack, multi-layered ...


3

I agree with what the other answers has commented: The title should be descriptive to know in a glance what will happen when the story is released. I would like to add some advice I use to write it, and it's use "When released, this story will...", as follow: "When released, this story will... " > "Send an email to Service Delivery when the order is ...


3

Limited Native Options; Flexible API Full-fledged, multi-project and multi-repository project management is not really what GitHub does best. You may want to explore third-party solutions for your bug tracking and milestone management if the native options aren't enough for you. GitHub has recently gained the notion of projects that span several ...


3

TL;DR A story point based burndown chart doesn't measure time remaining. It measures work-effort remaining, and you must use additional metrics to forecast your schedule based on current scope. Story Points, ZenHub, and Burndowns A story point based burndown chart doesn't measure time, it measures work remaining. I won't belabor the fact that canonically ...


2

I agree with everything Todd said, and want to add a few points: You note that Because any progress on the burn down chart is not indicated until we close the issue. This is by design. The idea behind Scrum is that if you have a Story that you've been working on for 3 days, and it isn't done yet, then that Story is 0% done. The reasoning behind this is ...


2

That's a good feature in GitHub. When you add a single comment, the reviewers of the PR are notified immediately. I don't use that. I start a review, make all my comments, and finish my review. By doing that, the reviewers are notified of all my comments at once. If you even change a single character in the code, it is neither a comment nor a code review; it'...


1

It feels like there's a (potentially well intended) motivation to set how development and architecture should work based on agility principles. As well meant as it could be, the way the question is framed it implies this may not be working. I'll approach the technical aspects (merge, commit, pull request, repo) from engineering perspective. The "agility&...


1

You can use a self-hosted repository such as gitlab or gitea/gogs. Gitlab is pretty full-blown with commercial and community (free) versions, gitea (which is a fork of gogs) and gogs are very light-weight. I run gitea on my private server for stuff on which I'm working from different development machines. For just 5 developers, it's probably all you need. ...


1

A title must be precise. The simpler the better. The prefix phrases like 'As a user', 'As a system administrator', 'As a business owner', 'As a developer' etc. are best suited for describing the acceptance criteria of the story. A simple title will make the story easy to refer to or look up.


1

Anton - I had a very similar problem. I ended up building out a platform to help with project forecasting. It has some light CRM features and some light time entry features but we'll be enhancing those in the coming weeks and months. Specifically, it will help you: Keep track of pipeline projects Forecast out time associated with a specific role and allow ...


1

Pablo from ZenHub here (answering the question since ZenHub was specifically mentioned). Most ZenHub features are multi-repository; you can add repositories to an existing Board so both backend and front-end issues will be in the same place. From the Board, you can create a multi-repo milestone, which creates matching milestones across all the repositories ...


1

The answer to this question is a simple one: you manage your work at the level of decomposition / abstraction necessary to manage your work. This is a plus / minus equation. On one hand, by keeping it at the higher level, you increase the ability for flexibility in the work and you save a ton of money in tracking and controlling. But on the other hand, ...


Only top voted, non community-wiki answers of a minimum length are eligible