Posts

Open Source Leadership Summit

Share your knowledge, best practices, and strategies at Open Source Leadership Summit.

Open Source Leadership Summit (OSLS) is an invitation-only think tank where open source software and collaborative development thought leaders convene, discuss best practices, and learn how to manage today’s largest shared technology investments.

The Linux Foundation invites you to share your knowledge, best practices, and strategies with fellow open source leaders at OSLS.  

Tracks & Suggested Topics for Open Source Leadership Summit:

OS Program Office

  • Consuming and Contributing to Open Source
  • Driving Participation and Inclusiveness in Open Source Projects
  • Standards and Open Source
  • Managing Competing Corporate Interests while Driving Coherent Communities
  • How to Vet the Viability of OS Projects
  • Open Source + Startup Business Models
  • Project Planning and Strategy
  • Internal vs. External Developer Adoption

Best Practices in Open Source Development / Lessons Learned

  • Contribution Policies
  • Promoting Your Open Source Project
  • Open Source Best Practices
  • Open Source Program Office Case Studies and Success Stories
  • Standards and Open Source

Growing & Sustaining Project Communities / Metrics and Actions Taken

  • Collaboration Models to Address Security Issues
  • Metrics for Understanding Project Health

Automating Compliance / Gaps & Successes

  • Using Trademarks in Open Communities
  • Working with Regulators / Regulated Industries
  • Working with the Government on OS
  • How to Incorporate SPDX Identifiers in Your Project
  • Legal + Compliance
  • Licensing + Patents
  • Successfully Working Upstream & Downstream

Certifying Open Source Projects

  • Security
  • Safety
  • Export
  • Government Restrictions
  • Open Source vs. Open Governance
  • New Frontiers for Open Source in FinTech and Healthcare

Futures

  • Upcoming Trends
  • R&D via Open Source
  • Sustainability

Business Leadership

  • Cultivating Open Source Leadership
  • How to Run a Business that Relies on Open Source
  • How to be an Effective Board Member
  • How to Invest in Your Project’s Success
  • Managing Competing Corporate Interests while Driving Coherent Communities
  • Monetizing Open Source & Innovators Dilemma

View here for more details on suggested topics, and submit your proposal before the Jan. 21 deadline.

Get inspired! Watch keynotes from Open Source Leadership Summit 2017.

See all keynotes from OSLS 2017 »

open source community

Zachary Dupont wrote a letter to his hero Linus Torvalds back in 2014. Here, they catch up on stage at Open Source Summit NA 2017.

The Linux Foundation works through our projects, training and certification programs, events and more to bring people of all backgrounds into open source. We meet a lot of people, but find the drive and enthusiasm of some of our youngest community members to be especially infectious. In the past couple of months, we’ve invited 13-year-old algorithmist and cognitive developer Tanmay Bakshi, 11-year-old hacker and cybersecurity ambassador Reuben Paul, and 15-year-old programmer Keila Banks to speak at Linux Foundation conferences.

In 2014 when he was 12, Zachary Dupont wrote a letter to his hero Linus Torvalds. We arranged for Zach to meet Linus–a visit that helped clinch his love for Linux. This year, Zach came to Open Source Summit in Los Angeles to catch up with Linus and let us know what he’s been up to. He’s kept busy with an internship at SAP and early acceptance to the Computer Networking and Digital Forensics program at the Delaware County Technical School.

The open source community encouraged Zach to pursue his passions. They’ve inspired him, and he plans to give back in the future.

We encourage everyone to find ways to bring more people of all ages into open source. Volunteer your time to teach students or people making mid-career changes how to code, spend time on writing documentation for your open source project so others can get to know it better, or simply take the time to answer beginner questions on message boards. The more people we bring into the community, the stronger we will be in the years ahead.

documentation

At the upcoming APIStrat conference in Portland, Taylor Barnett will explore various documentation design principles and discuss best practices.

Taylor Barnett, a Community Engineer at Keen IO, says practice and constant iteration are key to writing good documentation.  At the upcoming API Strategy & Practice Conference 2017, Oct. 31 -Nov. 2 in Portland, OR, Barnett will explain the different types of docs and describe some best practices.

In her talk — Things I Wish People Told Me About Writing Docs — Barnett will look at how people consume documentation and discuss tools and tactics to enable other team members to write documentation.  Barnett explains more in this edited interview.

The Linux Foundation: What led you to this talk? Have you encountered projects with bad documentation?

Taylor Barnett: For the last year, my teammate, Maggie Jan, and I have been leading work to improve the developer content and documentation experience at Keen IO. It’s no secret that developers love excellent documentation, but many API companies aren’t always equipped with the resources to make that happen. As a result of this, we all come across a lot of bad documentation when you are trying to use developer tools and APIs.

The Linux Foundation: Often, there is a team of documentation writers and there are developers who wrote that piece of software; both are experts in their own fields, but they need a lot of collaboration to create usable docs. How can that collaboration be improved?

Barnett: In large companies, this can definitely be true, although in many companies documentation is still owned by various teams. The need for more collaboration still applies, though. One way to improve collaboration is bringing docs into the product development process early on. If you wait until everything is done and going to be released soon, people writing documentation are going to feel left out of the process and like an afterthought. If people working on the product development collaborate early on, not only does the product become better, but so does the documentation. People who are writing documentation usually spend some time figuring out the API or tool they are writing about, so they only get better when they can work with the people doing product development early on. Also, they can give great feedback from a user’s perspective much earlier in the process.

Another way to improve collaboration is to bring more people into the documentation review process. We do most of our documentation reviews in GitHub. It’s great to not only have someone in the role of an editor review it but also people from the Engineering or Product teams. It increases the number of eyes on the docs and helps make them better.

The Linux Foundation: How should developers approach documentation?

Barnett: Most developers are pretty familiar with the idea of Test Driven Development (TDD), but how familiar are they with Documentation Driven Development (DDD)? The flow for DDD is:

  1. Write or update documentation,
  2. Get feedback on that documentation,
  3. Write a failing test according to that documentation (TDD),
  4. Write code to pass the failing test,
  5. Repeat.

It can be an excellent way for developers to save a lot of time and prevent spending too much time on poorly designed features. As Isaac Schlueter, co-founder of npm, says about Documentation Driven Development, writing clear prose is an “effective way to increase productivity by reducing both the frequency and cost of mistakes.” Our brains can only hold so much information at once. In computer terms, our working memory size is pretty small. Writing down some of the information we are thinking about is a way to “off-load significant chunks of thought with hardly any data-loss,” while allowing us to think slower and more carefully.

For example: At Keen IO, we recently split our JavaScript library into three different modules. This decision was inspired by the documentation we were maintaining. We had tried to streamline the docs, but there was just too much to cover in an attention-constrained world. Many important details and features were hidden in the noise. For example, if all of the documentation was written sooner, we may have made this decision sooner.

Also, as a developer who is writing docs myself, constant iteration and practice are important. Your first version of the docs aren’t going to be great, but with focusing on trying to write clear prose, they will get better with time. Also, having another person who is not familiar with the product and can step through the documentation to review it is essential.

The Linux Foundation: If developers are writing documentation for other developers, how can they really think as the users?

Barnett: I used to think that developers are the best people to write docs for other developers because they are one of them. While I still believe this is partially true, some developers also assume a lot of knowledge. If it has been a while since a developer has done something, the “curse of knowledge” can exist. The more you know, the more you forget what it was like before. That’s why I like to talk about empathic documentation.

You need to empathize with the user on the other end. Don’t assume they know how to do something and give resources to fill in the steps that might seem “easy” to you. Also, hearing that something is “easy” or “simple” when something is not working on the user’s’ end is the worst feeling. It makes your users doubt themselves, feel frustrated, and a bunch of other negative emotions. Always try to remember you need to be empathetic!

The Linux Foundation: What’s the importance of tools in creating documentation?

Barnett: Very important! Earlier I mentioned using GitHub for reviews. I also would recommend having some continuous integration testing in place for your documentation site if you aren’t using a service like ReadMe or Apiary to make sure you don’t break it. A related topic is, do you build your own thing or use a service? Tools can be helpful, but they might not always be the best fit. You have to find a balance based on your current resources. Lastly, I would recommend checking out Anne Gentle’s book, Docs Like Code. She brings up tools a lot in the book.

The Linux Foundation: Who should attend your session?

Barnett: Everyone! Just kidding (kind of). If you are in any role that is developer facing like developer relations, evangelists, advocates, marketers, etc., if you are on a Product team for a developer focused product or platform, or if you are a developer or engineer who wants to write better docs.

The Linux Foundation: What is the main takeaway from your talk?

Barnett: Anyone can write docs, but with some practice, iteration, and working on different documentation writing skills anyone can write better docs.

Learn more in Taylor Barnett’s talk at the APIStrat conference coming up Oct. 31 – Nov. 2 in Portland, Oregon.

APIs

Learn tricks, shortcuts, and key lessons learned in creating a Developer Experience team, at APIStrat.

Many companies that provide an API also include SDKs. At SendGrid, such SDKs send several billions of emails monthly through SendGrid’s Web API. Recently, SendGrid re-built their seven open source SDKs (Python, PHP, C#, Ruby, Node.js, Java, and Go) to support 233 API endpoints, a process which I’ll describe in my upcoming talk at APIStrat in Portland.

Fortunately, when we started this undertaking, Matt Bernier had just launched our Developer Experience team, covering our open source documentation and libraries. I joined the team as the first Developer Experience Engineer, with a charter to manage the open source libraries in order to ensure a fast and painless integration with every API SendGrid produces.

Our first task on the Developer Engineering side was to update all of the core SendGrid SDKs, across all seven programming languages, to support the newly released third version of the SendGrid Web API and its hundreds of endpoints. At the time, our SDKs only supported the email sending endpoint for version 2 of the API, so this was a major task for one person. Based on our velocity, we calculated that it would take about 8 years to hand code every single endpoint into each library.

This effort involved automated integration test creation and execution with a Swagger/OAI powered mock API server, documentation, code, examples, CLAs, backlogs, and sending out swag. Along the way, we also gained some insights on what should not be automated — like HTTP clients.

In my talk at APIStrat, I am going to share some tricks, automations, shortcuts, and key lessons that I learned on our journey to creating a Developer Experience team:

  • We will walk through what we automated and why, including how we leveraged OpenAPI and StopLight.io to automate SDK documentation, code, examples, and tests.
  • Then we’ll dive into how we used CLA-Assistant.io to automate CLA signing and management along with Kotis’ API to automate sending and managing swag for our contributors.
  • We’ll explore how these changes were received by our community, how we adapted to their feedback and prioritized with the RICE framework.

If you’re interested in attending, please take a moment to register and sign up for my talk. I hope to see you there!

OpenStack Summit Sydney

OpenStack Summit Sydney offers 11+ session tracks and plenty of educational workshops, tutorials, panels. Start planning your schedule now.

Going to OpenStack Summit Sydney? While you’re there, be sure stop by The Linux Foundation training booth for fun giveaways and a chance to win a Raspberry Pi kit. The drawing for prizes will take place 1 week after the conference on November 15.

Giveaways include The Linux Foundation projects’ stickers, and free ebooks: The SysAdmin’s Essential Guide to Linux Workstation Security, Practical GPL Compliance, A Guide to Understanding OPNFV & NFV, and the Open Source Guide Volume 1.

With 11+ session tracks to choose from, and plenty of educational workshops, tutorials, panels — start planning your schedule at OpenStack Summit in Sydney now.

Session tracks include:

  • Architecture & Operations
  • Birds of a Feather
  • Cloud & OpenStack 101
  • Community & Leadership
  • Containers & Cloud-Native Apps
  • Contribution & Upstream Development
  • Enterprise
  • Forum
  • Government
  • Hands-on Workshop
  • Open Source Days
  • And More.

View the full OpenStack Summit Sydney schedule here.

Cloud Native Computing Foundation and Cloud Foundry will also have a booth at OpenStack Summit Sydney. Get your pass to OpenStack and stop by to learn more!

MesosCon

Sign up for free live video streaming of all keynote sessions at MesosCon Europe.

Can’t make it to MesosCon Europe in Prague this week? The Linux Foundation is pleased to offer free live video streaming of all keynote sessions on Thursday, Oct 26 and Friday, Oct 27, 2017.

MesosCon is an annual conference organized by the Apache Mesos community, bringing together users and developers to share and learn about the project and its growing ecosystem. Users, developers, experts, and community members will convene next week.

Apache Software Foundation, Mesosphere, and Netflix are among the many organizations that will keynote next week.

The livestream will begin on Thursday, Oct. 26 at 9 a.m. CEST (Central European Summer Time). Sign up now! You can also follow our live event updates on Twitter with #MesosCon.

All keynotes will be broadcasted live, including a welcome and opening remarks by Ben Hindman, Co-Creator, Apache Mesos and Founder, Mesosphere.

Other featured keynotes include:

  • Rich Bowen, VP Conferences, Apache Software Foundation will analyze The Apache Way.
  • Katharina Probst, Netflix will talk about making and keeping Netflix highly available.
  • SMACK in the enterprise panel.
  • Pierre Cheynier, Operations Engineer, Criteo will discuss operating 600+ Mesos servers on 7 data centers.
  • And more.

View the full schedule of keynotes.

Sign up now for the free live video stream.

Once you sign up, you’ll be able to view the livestream on the same page. If you sign up prior to the livestream day/time, simply return to this page and you’ll be able to view.

Open Source Summit EU

Going to Open Source Summit? Check out some featured conference presentations and activities below.

Going to Open Source Summit EU in Prague? While you’re there, be sure stop by The Linux Foundation training booth for fun giveaways and a chance to win one of three Raspberry Pi kits.

Giveaways include The Linux Foundation branded webcam covers, The Linux Foundation projects’ stickers, Tux stickers, Linux.com stickers, as well as free ebooks: The SysAdmin’s Essential Guide to Linux Workstation Security, Practical GPL Compliance, and A Guide to Understanding OPNFV & NFV.

You can also enter the raffle for a chance to win a Raspberry Pi Kit. There will be 3 raffle winners: names will be drawn and prizes will be mailed on Nov. 2.

And, be sure to check out some featured conference presentations below, including how to deploy Kubernetes native applications, deploying and scaling microservices, opportunities for inclusion and collaboration, and how to build your open source career.

Session Highlights

  • Love What You Do, Everyday! – Zaheda Bhorat, Amazon Web Services
  • Detecting Performance Regressions In The Linux Kernel – Jan Kara, SUSE
  • Highway to Helm: Deploying Kubernetes Native Applications – Michelle Noorali, Microsoft
  • Deploying and Scaling Microservices with Docker and Kubernetes – Jérôme Petazzoni, Docker
  • printk() – The Most Useful Tool is Now Showing its Age – Steven Rostedt, VMWare
  • Every Day Opportunities for Inclusion and Collaboration – Nithya Ruff, Comcast

Activities

  • Technical Showcase
  • Real-Time Summit
  • Free Day with Prague tour from local students
  • KVM Forum
  • FOSSology – Hands On Training
  • Tracing Summit

The Cloud Native Computing Foundation will also a have booth at OSSEU. Get your pass to Open Source Summit Europe and stop by to learn more! Use discount OSSEULFM20 code for 20% off your all-access attendee pass.

Check out the full list of co-located events on the website and register now.

Join the Apache Mesos community in Prague for town halls, MesosCon university, and a full-day hackathon.

Get the latest on Apache Mesos with Ben Hindman, Co-Creator of Apache Mesos, at MesosCon Europe taking place October 25-27, 2017 in Prague, Czech Republic. At the conference, you’ll hear insights by industry experts deploying Mesos clusters, learn about containerization and security in Mesos, and more.

This annual conference brings together users and developers to share and learn about the Mesos project and its growing ecosystem. The conference features two days of sessions focused on the Apache Mesos Core and related technologies, as well as a one-day hackathon, town halls, and MesosCon University.  

Highlights include:

  • SMACK in the Enterprise keynote panel: Hear how the SMACK stack is impacting the data analytics landscape at large enterprises. Panelists will be announced soon.
  • MesosCon University: Tutorial-style sessions will offer hands-on learning for building a stateful service, operating your cluster, or bootstrapping a secure Mesos cluster.
  • Town Halls: A community gathering to discuss pressing needs and issues. The town halls will begin at 7:00pm after the onsite reception on Thursday, and will include drinks and appetizers sponsored by Mesosphere. Have a town hall you think we should run? Reach out to events@linuxfoundation.org.
  • Hackathon: Come and work on new Mesos features, new demos, new documentation, and win great prizes! The Hackathon will take place on Wednesday, October 25, and is included with your conference registration.  

View the full schedule of sessions and activities here.

Get a preview of what to expect at MesosCon Europe. Watch videos from MesosCon North America 2017 here.

Register now and use discount code MCEULDC17 to save $25 off your pass to MesosCon Europe.

Reuben Paul, co-founder of CyberShaolin, will speak at Open Source Summit in Prague, highlighting the importance of cybersecurity awareness for kids.

Reuben Paul is not the only kid who plays video games, but his fascination with games and computers set him on a unique journey of curiosity that led to an early interest in cybersecurity education and advocacy and the creation of CyberShaolin, an organization that helps children understand the threat of cyberattacks. Paul, who is now 11 years old, will present a keynote talk at Open Source Summit in Prague, sharing his experiences and highlighting insecurities in toys, devices, and other technologies in daily use.

Reuben Paul, co-founder of CyberShaolin

We interviewed Paul to hear the story of his journey and to discuss CyberShaolin and its mission to educate, equip, and empower kids (and their parents) with knowledge of cybersecurity dangers and defenses.  

Linux.com: When did your fascination with computers start?
Reuben Paul: My fascination with computers started with video games. I like mobile phone games as well as console video games. When I was about 5 years old (I think), I was playing the “Asphalt” racing game by Gameloft on my phone. It was a simple but fun game. I had to touch on the right side of the phone to go fast and touch the left side of the phone to slow down. I asked my dad, “How does the game know where I touch?”

He researched and found out that the phone screen was an xy coordinate system and so he told me that if the x value was greater than half the width of the phone screen, then it was a touch on the right side. Otherwise, it was a touch on the left side. To help me better understand how this worked, he gave me the equation to graph a straight line, which was y = mx + b and asked, “Can you find the y value for each x value?” After about 30 minutes, I calculated the y value for each of the x values he gave me.

“When my dad realized that I was able to learn some fundamental logics of programming, he introduced me to Scratch and I wrote my first game called “Big Fish eats Small Fish” using the x and y values of the mouse pointer in the game. Then I just kept falling in love with computers.Paul, who is now 11 years old, will present a keynote talk at Open Source Summit in Prague, sharing his experiences and highlighting insecurities in toys, devices, and other technologies in daily use.

Linux.com: What got you interested in cybersecurity?
Paul: My dad, Mano Paul, used to train his business clients on cybersecurity. Whenever he worked from his home office, I would listen to his phone conversations. By the time I was 6 years old, I knew about things like the Internet, firewalls, and the cloud. When my dad realized I had the interest and the potential for learning, he started teaching me security topics like social engineering techniques, cloning websites, man-in-the-middle attack techniques, hacking mobile apps, and more. The first time I got a meterpreter shell from a test target machine, I felt like Peter Parker who had just discovered his Spiderman abilities.

Linux.com: How and why did you start CyberShaolin?
Paul: When I was 8 years old, I gave my first talk on “InfoSec from the mouth of babes (or an 8 year old)” in DerbyCon. It was in September of 2014. After that conference, I received several invitations and before the end of 2014, I had keynoted at three other conferences.

So, when kids started hearing me speak at these different conferences, they started writing to me and asking me to teach them. I told my parents that I wanted to teach other kids, and they asked me how. I said, “Maybe I can make some videos and publish them on channels like YouTube.” They asked me if I wanted to charge for my videos, and I said “No.” I want my videos to be free and accessible to any child anywhere in the world. This is how CyberShaolin was created.

Linux.com: What’s the goal of CyberShaolin?
Paul: CyberShaolin is the non-profit organization that my parents helped me found. Its mission is to educate, equip, and empower kids (and their parents) with knowledge of cybersecurity dangers and defenses, using videos and other training material that I develop in my spare time from school, along with kung fu, gymnastics, swimming, inline hockey, piano, and drums. I have published about a dozen videos so far on the www.CyberShaolin.org website and plan to develop more. I would also like to make games and comics to support security learning.

CyberShaolin comes from two words: Cyber and Shaolin. The word cyber is of course from technology. Shaolin comes from the kung fu martial art form in which my dad and are I are both second degree black belt holders. In kung fu, we have belts to show our progress of knowledge, and you can think of CyberShaolin like digital kung fu where kids can become Cyber Black Belts, after learning and taking tests on our website.

Linux.com: How important do you think is it for children to understand cybersecurity?
Paul: We are living in a time when technology and devices are not only in our homes but also in our schools and pretty much any place you go. The world is also getting very connected with the Internet of Things, which can easily become the Internet of Threats. Children are one of the main users of these technologies and devices.  Unfortunately, these devices and apps on these devices are not very secure and can cause serious problems to children and families. For example, I recently (in May 2017) demonstrated how I could hack into a smart toy teddy bear and turn it into a remote spying device.
Children are also the next generation. If they are not aware and trained in cybersecurity, then the future (our future) will not be very good. 

Linux.com: How does the project help children?
Paul:As I mentioned before, CyberShaolin’s mission is to educate, equip, and empower kids (and their parents) with knowledge of cybersecurity dangers and defenses.

As kids are educated about cybersecurity dangers like cyber bullying, man-in-the-middle, phishing, privacy, online threats, mobile threats, etc., they will be equipped with knowledge and skills, which will empower them to make cyber-wise decisions and stay safe and secure in cyberspace.
And, just as I would never use my kung fu skills to harm someone, I expect all CyberShaolin graduates to use their cyber kung fu skills to create a secure future, for the good of humanity.

Improve the efficiency of your software development team with the RICE framework. Learn more at the upcoming APIStrat conference in Portland, Oregon.

The Developer Experience team at SendGrid is a small, but mighty force of two. We attempt to tackle every problem that we can get our hands on. This often means that some items get left behind.  At the outset, we surveyed everything that was going on in our open source libraries and we quickly realized that we needed to find a way to prioritize what we were going to work on. Luckily, our team lives, organizationally, on the Product Management team, and we had just received a gentle nudge and training on the RICE prioritization framework.

On our company blog, I wrote an article about how employing this framework, using a spreadsheet, helped us double our velocity as a team within the first sprint. Our development velocity doubled because the most impactful things for the time spent are not always the biggest things, but the biggest things tend to attract the most attention due to their size.

What is RICE?

RICE as an acronym stands for Reach x Impact x Confidence, all divided by Effort. This calculation allows you to get a score that weighs the following. Some of the definitions we use are a slight departure from Intercom’s original version, but this has been very effective for us!

The calculation:

Reach * Impact * Confidence

————————————–

               Effort

This gives us a score for every item in our list. Then, we sort our list in descending order by score. We realized, once we had a sorted list, that we accidentally made a Kanban backlog. We worked from the top of the list, keeping work in progress (WIP) to as much of a minimum as possible. WIP can be tough with open source, because we often have 20-30 issues waiting for a community member response. These items sit at the top of our backlog, and we look into them at the start of every day in the hope that we can clear them out of our WIP category.

Lessons Learned

Reach – The number of customers this will affect

One thing we learned about using RICE is making sure that we use consistent numbers for each of the variables in the calculation. It was very tempting for us, an email company, to use the “number of emails” sent as the Reach parameter. This worked until we started trying to evaluate tasks that didn’t have anything to do with our v3/mail/send endpoint. We eventually settled on number of customers using this library for this purpose”, calculating API user count and mail user count for the Reach.

Impact – A measure of the effect completing this project will have

It is easy to assume that every single item is a high or massive priority. It looks nice, gives you an ego boost, and totally messes up everything in your ranking system. Be honest with yourself about what is on your list. If things don’t really seem to be in the right place in your list (more on this below) then look at impact, because it’s probably artificially high, especially in context of the items around it in the list.

Confidence – How confident are we that we can sit down and complete this task today

We use a text-based selection from the list: None, Minimal, Low, Medium, High, and “with my eyes closed”.  These each translate into specific numbers for the calculation.

Effort – The number of story points will this take to complete

We use story points because this approach allows us to figure out the calendar length of a task rather than the aggregate of specific amounts of time spent on the task. To be more specific, this is the difference between “It’s going to take 3 hours” and “It will only take 3 hours of work, but it won’t be finished until Friday.” This is an easy trap to fall into, because new projects are exciting and we want to jump in and knock them out. That doesn’t mean that we can actually get a project that “will only take a couple days” done within the same month we started it. Life happens, your velocity calculation accounts for that — especially if you use an average over the last year (get out yer agile pitchforks!).

Letting the backlog win

We have learned the hard way with projects we really want to work on right now, that they are not always the right project at the moment. It is important to have confidence in the calculation and take the assumption that it is correct. That is, until you are looking at the list and realize that “Hey, item 15 really should be item 5. What’s going on here?” Look at your list in context of the other items, does the order feel correct? If not, why not?

We ended up using RICE as the baseline calculation for everything we do, but it is not the end-all. We added in calculation modifiers for company priority, due dates, and status — because something the executives have on the company roadmap, that has to be done in Q3, should be worked on right away. And, because we are using Kanban, the status of an item is important. Once you start something, it should stay at the top of the list until it is done, or you decide it is no longer necessary to complete it. Getting WIP completed, rather than backed up, is a good way to see the impact of your work and get a sense of accomplishment for yourself and your development team.

Matt Bernier is the Developer Experience Product Manager at SendGrid, where he spends most of his time digging into customer feedback in order to provide a World Class Experience for Developers with SendGrid.

Learn more in Matt Bernier’s talk — How We Doubled the Velocity of Our Developer Experience Team — at the APIStrat conference coming up Oct. 31 to Nov. 2 in Portland, Oregon.