Cards on the Kanban Board and the Sprint Board now show related GitHub Pull Request information right on the front of the card. Previously, it was possible to see all the related Pull Requests (and other cards) on the card show view, and that hasn’t changed. What’s new is that Pull Request information is now available on the front of the card, so you can get a handle on related Pull Requests and their statuses at a glance.
There are two common ways teams use Pull Requests. One approach is to use Pull Requests to scope code that’s supposed to be deployed together, perhaps as a release. These Pull Requests tend to be quite large and include lots of code changes. The benefit of using Pull Requests in this fashion is that once the Pull Request is merged, you know that your code is ready to ship. Another benefit is that there tends to be only a few Pull Requests open at a time, and there may only be one active Pull Request. This makes it easy to focus on getting your code ready to ship without extra management overhead. The downside is that your Pull Requests drag out for a very long time and become quite bloated with code that might not sum up to solve any business objective.
Another approach to using Pull Requests is to have them define a feature that you’re building. This approach is more popular with teams that have implemented continuous deployment. The benefit of having your Pull Requests define a feature is that the code that’s wrapped up into them works together to solve a business objective. Merging the Pull Request means that you’ve successfully implemented at least one unit of value for the company. This aligns itself more naturally with the philosophy of Agile project management, where a collection of user stories (Cards) sum up to describe a feature (Pull Request). The downside of using Pull Requests to define features is that there tends to be a lot of them around at the same time and you need to make sure none of them are slipping through the cracks.
We hope the new Pull Request information on the front of cards will make it easier for you to quickly determine which cards are part of your pull requests and let you ship with confidence, no matter what approach your team uses.