Twitter Facebook
Follow Grindr on
Download Learn More Gear Blog Events Press Contact Help

Grindr Blog

The official Grindr blog.
News and more from Team Grindr.

Grindr’s Location Security Update

Posted on September 5, 2014 by Grindr Team

In response to recent security allegations surrounding location data, Grindr is taking proactive measures to keep users safe in territories with a history of violence against the gay community. Any user who connects to Grindr is these countries will have their distance hidden automatically by default, which include Russia, Egypt, Saudi Arabia, Nigeria, Liberia, Sudan and Zimbabwe. There are many more countries already being protected by this location change, and we will continue to add more to this list.

This change means that any user within these countries will not show distance on their profile (e.g. 1 mile away). Your location will not be able to be determined via trilateration or any other method, keeping your position private and secure. This change will not have any other effects on the Grindr experience as a whole: guys nearby will still populate in the correct order, with the first guy in the cascade being the closest to you.

Users that are not located in countries with anti-gay legislation will be able to see distance in profiles, as we believe geo-location technology is the best way to help guys meet up simply and efficiently. However, should you wish to hide your location data, simply open the side menu, tap ‘Settings’, then ‘Privacy’ and turn ‘Show Distance’ off.

There is nothing that matters to us more than the safety and security of our user and the Grindr community. We will continue to find ways to keep our users private, especially in countries with anti-gay legislation.

Stay tuned for continued enhancements and new features in our upcoming app updates.

Grindr Security

Posted on August 28, 2014 by Grindr Team

There have been recent reports that Grindr has an alleged security flaw and we wanted to clarify the matter with you all. There is nothing that matters more to us than our users and protecting the Grindr community is a core priority.  As part of the Grindr service, users rely on sharing location information with other users as a core function of the application. We are always focused on doing what we’ve set out to do from the beginning: help guys meet other guys. Grindr’s geolocation technology is the best way for users to meet up simply and efficiently.  As such, we do not view this as a security flaw.

For Grindr users concerned about showing their proximity, we make it very easy for them to remove this option and we encourage them to disable ‘show distance’ in their privacy settings. If a user wishes to turn off his distance setting, all he needs to do is toggle the show distance option in Settings. The app will still work, however other users won’t be able to see exactly how far they are.

We are continuously updating our platform to increase security across our networks and we do our best to keep our Grindr community secure.  Stay tuned for continued enhancements and new features in our upcoming app updates.

Part (1 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Posted on July 22, 2014 by Grindr Team

Part (1 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

00:04> Lukas Sliwka: Ok, so let’s get started, yeah? Perfect, good crowd. So let me introduce myself and also my partner in crime Elizabeth. My name is Lukas Sliwka and I am a VP of engineering here in GRINDR. I have been with the company for 8 months now; it’s kind of crazy to say 8 months because it seems like I just joined yesterday. Elizabeth’s been with us also that long. And today we’ll be focusing on SCRUM. But before I go into that topic I wanted to talk a little bit about GRINDR to give you a kind of a context what we are and what we do. So GRINDR is a company that focuses on gay dating up. We have Blackberry, Android and IOS clients; we have a lot of users around the globe; we have got users in over 190 countries. We serve massive-massive traffic; just to give you some metrics, we process around 5000 transactions per second, technology-wise we have Redis Clusters scale to be able to do 110000 queries per second. So we serve solving some pretty serious engineering challenges. 

**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


1:19> But today we are not going to be focusing on code, today we are going to be focusing on SCRUM and Agile practices. And the reason why is because at the end of the day as we are building engineering at GRINDR, we are focusing on QA practice, automation practice, mobile development including, you know, IOS, Android backing development, architecture, obviously… There are all these different engineering practices, but at the end of the day, when it comes to actual delivery and the rubber meets the road, you need Agile office and SCRUM or Agile practices in order for all these different functional areas to come together and deliver software, right? So I’m not going to spend too much time talking about Agile and SCRUM because those are really not new concepts. I will share those some of my learnings; I have been doing SCRUM for many years now and I am very, by the way, opinionated about the subject, as you will find out. And I am also very passionate about the subject because what I’ve seen in the past is that you cannot have a successful innovating engineering organization without having a strong SCRUM and Agile practice, that’s downright. Unfortunately, SCRUM and Agile has gotten a bad name and that is because there is a lot of hacks out there that claim to do it but they don’t really do it. The Agile organization as it is shaped today doesn’t really help matters because you can really get SCRUM certification or SCRUM master’s certification very easily. And the fact that you’ve got it doesn’t really mean that you can actually do it, right? So I’m gonna talk about that; there is a section in our presentation to talk about, from my experience, what you must be doing if you want to do it right. So… Come on now… Got technical difficulties… OK that worked.

3:42> So, a couple of things I want to focus on today, so again; what is SCRUM and what it is not. I am going to spend most of my time talking about what it is not. We will also talk about how to successfully implement SCRUM (I am not going to recite to you from articles or from books or whatever, I’m just gonna talk about my own experiences and hopefully you will find that useful) and then we are going to dive into SCRUM metrics. So that area is something that you don’t normally see in a lot of organizations. I mean you do things like Velocity, right? Everyone knows what Velocity is, people know how to use, hopefully, Fibonacci measure SCRUM with story points and all that good stuff. But there is many-many other metrics that you may find useful. Especially if you are coming from a heavy PMO background or if you still have a heavy PMO presence in your organization and you need to forecast things or justify things, if you want to translate sprints into measure of, you know, ‘how much it’s gonna cost me’, there is a way to do that. And then Elizabeth is going to actually talk about mechanics of how we gather and how we use metrics here at GRINDR, right? So I’m gonna focus on just concepts, I’m gonna talk about my experiences and then we’ll dive in, once Elizabeth gets up here, to talk about how we actually do it here.

5:21> So, when it comes to all this stuff, I cannot continue without also giving credit to Scott Downey who is our Agile coach. He is hiding somewhere. He is right there (pointing at the audience). I have worked with that man for many-many years. He’s been working very closely with Jeff Sutherland on this stuff. He actually invented, documented and showed how to calculate a lot of that stuff. If you want more-more detail and actually dive in some of his presentations, some of the spreadsheets that he has available, you can go to his website, there, is a lot of goodies there for you to download. And also, he’s available for hire (laughing). Ok, so that’s enough of that, that’s a shameless plug.

6:19> So before we go further, how many of you have actually heard of SCRUM before? Yes, yes, ok (looking at the reaction of the audience). And how many of you think that you are doing SCRUM today? Ok, great (gives a laugh when no one responds). So one thing that I want to kick it off with is that I want to put an emphasis on the fact that people talk about SCRUM as being a lot of different things, but at the end of the day it’s simply a framework for effective team collaboration. And, you know, it brings some processes and roles into a picture that make things easier but at the end of the day it’s a collaboration framework. So, it essentially provides enough rules that allow your teams to self-organize and essentially provide an ecosystem that allows you to kind of get out of the way and allow teams to self-organize and hopefully become hyper productive. So, in my experience what I’ve seen is that when you start doing SCRUM, it is very difficult to just smash people together and say ‘Ok, go to a training and do SCRUM’. A lot of times it takes hiring of a qualified Agile coach; it takes to hire a qualified SCRUM master. There is a lot of different things that you have to do to enable SCRUM. But before we go there I wanna talk about from a very high level of perspective what are some of the ingredients to doing SCRUM correctly. I included here a very simple diagram that you might have seen in the past. There are a couple of concepts here that I want to highlight: product backlog, it’s something very important. And that, kind of, correlates to the role of a SCRUM product owner. The SCRUM product owner is a very important function in SCRUM because that’s a person that is responsible for all the user story, for all the things that you are asking from the team to build, right? So it’s essentially a dedicated person that is working very closely with the team and they need to be available to the team at all times to be able to answer questions. So, they are the ones who’re actually writing the user stories. I am not going to be getting into user story writing and talking about what makes a good user story. I think you can get that from a lot of articles on the web, also you can go to Scott’s website you can get all that. But there are, essentially, rules and regulations when it comes to how to write user stories, what makes a user story actionable and how a team can actually execute on user story. But product backlog is essentially something that is on by product owner, they are prioritizing that list of user stories and one thing that’s important here is that before anything goes into sprint backlog, a product owner can actually go and change priorities all the time, right? So, this is a very fluid type of list. That’s very important because one thing about SCRUM is its very iterative nature, so you want to have incremental and iterative time boxes in which you build software. People say that SCRUM teams are usually operating 2 to 4 weeks. I would say that the best way to build software is in one-week sprint. It’s not very easy to achieve but I think that if you look at your engineering practice as a whole, the engineering practice as a whole needs to enable you to get delivery practice. So in order for you to be successful in one-week sprints, you have to have certain things that you need to have in place. For example, QA automation, right? If you are regression testing or testing takes, you know, a long time, then you may not be able to move ice quickly. If you don’t have a strong release management and build pipeline that is tight with your continuous integration, then you may not be able to do one-week sprints because everything takes long time. So, as you’re adapting SCRUM, you have to remember that there is a lot of supporting engineering practices; they are enabling SCRUM or enabling Agile, and without them it’s kind of very difficult to do, right? 11:12> Another thing is Sprint backlog that I mentioned. Sprint backlog is essentially a list of user stories that the team commits to during the sprint planning. There is a formal session that the SCRUM team would go through with the product owner and the SCRUM master and essentially they would work in the order of priority to evaluate each user story that the product owner is introducing from the perspective of, you know, ‘is this actionable, do I have all the assets, can we actually… is this immediately actionable’. So, there is so much of different principles that you should usually check whether you can accept the user story into a sprint; long story, short… Sprint planning and sprint backlog is essentially this concept of a team’s committing to a body of work, right? Now, when we talk about metrics, this is kind of one of the first touch points when you can say metrics become applicable. And we will talk further down the presentation, but if you know your team’s velocity, you have everything estimated, then as a SCRUM master and a product owner you can kind of take a guess in terms of how much work can be actually accomplished by the team for that sprint, so you can start projecting things.

12:36> I talked about sprint duration; I’ve done three-week sprints, I’ve done two-week sprints, I’ve done one-week sprints… I can tell you here in GRINDR we do one-week sprints. It’s taken us a while to get there. When we started with this we were on two-week sprints, and the last 6 months we’ve introduced a lot of these supporting practices that I talked about. So we have now fully automated Jenkins build and release management, pipeline for IOS and Android; we’re actually calculating code metrics, so a lot of code reviews and code quality type of stuff happens automatically and you are starting to fail builds if you are not conforming to those kind of metrics. And in addition to that, we’re also doing… we’re just about to kick off the automation of our smoke test and by the midsummer we’ll have this 80% of our ration testing automated as well. So if you have all that in place, you can start thinking about ‘ok, let’s shorten our development cycle to 5 days’. If we were to compare what GRINDR was a year ago, GRINDR was doing good old waterfall at a time, or they thought we’re doing SCRUM, I don’t know… But there were 3 IOS releases that year. Between now and then, this year we had 20-22, something like that. So close to 20 releases just in 6 months. So that kind of gives you an idea how much quicker you can move, right? And you want to do it in high confidence, right? The whole point of doing this is to allow the team to fail fast, right? Agile and SCRUM is to organize your work and allow the team to be very hyper productive but also you’re putting all the mechanisms in place allowing the team to maybe experiment with things and fail very fast and find out, ok, way before it actually goes into testing or production, that something’s wrong, right? And they can calibrate, and they can rinse and repeat, right? 

**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


14:54> Ideally, at the end of the sprint you want to have production ready deliverables. A big mistake that a lot of companies do is that they say “Ok well, this is sprint we’re gonna do development and the next spring we’re gonna do testing, and the sprint after that we’re gonna do regression testing”. And that’s not SCRUM, that’s not Agile, that’s ‘scrumaful’. What essentially needs to happen is that within your sprint you need to do all of these activities resulting in a deliverable shippable product, right? Which means that as part of the sprint, you need to have developers, your QA, any sort of other functional areas working together, so if you have architecture practice, then you review things, then they need to work very closely with the team to make sure that all these things happen at the same time. So, from the process perspective again going back to supporting practices you kind of have to think through how all these things flow together, right? How are you going to leverage automation tool or any sort of tools available in the market to enable your team? So the way we do code reviews; we use pull requests and bitbucket. That's on the low level. Then on the higher level we also have very collaborative sprint planning sessions that sometimes take a day... Or half a day, right? So sprint planning is the time when the team is supposed to be looking at the code, they are supposed to be talking about architecture, if you want a solutions architect present doing those sessions to kind of validate the approach, then they need to be available; you need to schedule that. So that way by the time the team is done with the planning, they know exactly what the architecture should be; it’s already validated, we made sure that it conforms with our architecture practice and they can just go-go-go and build the stuff in the next five days. The same thing goes for testing. So the testers at the same time need to plan their test cases, figure out how to augment automation sweep. So you know, the QA practice have to essentially enable SCRUM to be able to do this one-week sprint, right?

17:12> OK, let’s talk about the SCRUM master. That’s a very… very key role, and it’s a very interesting role too, because a good SCRUM master overtime is no longer necessary… In an ideal world, right? I have not seen that happen ever, but that’s what I’ve heard. Ideally you want to essentially enable the team and coach the team to the extent where they just kind of become Agile by osmosis, I suppose. But the reality is that this is a very key role. One thing that I would say here is that in the world of coaching there are a lot of SCRUM masters who are essentially project managers that went to SCRUM training and that doesn’t make you a SCRUM master. SCRUM training doesn’t give you, you know, it gives you a license to drive maybe but if you want to ride in a competitive race course, that’s not gonna happen. So, and I’m gonna talk about that a little bit later, you know, if you want to do it right, there are some key steps that you need to do as an organization to make sure that you don’t mess and you actually enable people right.

18:31> And then there is a SCRUM team. I touched about that a little bit already. So again, SCRUM teams are cross functional. One thing that I wanna say is that – and I see some of my guys here in the audience – I give this spiel over and over and over for people who work for me; I don’t micromanage people. I treat each SCRUM team as a startup.

19:03> So, our company backlog is essentially a product that you‘re building as startup. I will provide you with engineering guidelines; things like “ok, well, we agreed as engineering that we will do test-driven development, we agreed that we’re going to conform to certain coding standards, so there are some underlining principles that I will enforce, hopefully, through a lot of automation. But aside from that, it’s up to you, the SCRUM team, to kind of coalesce and figure it out. So if you want to innovate, if you wanna… do whatever it takes essentially in the most efficient and collaborative way, right? It’s actually pretty fun to watch, when you stop doing this command-control approach that you see in a lot of organizations that are PMO driven where you have to have an architect to decompose the work, and you have to have a manager to figure out who should be working on different pieces, and then you have one project manager, a side page developer… By the way, and I have seen that ratio where you have one PM per developer too, which is crazy and that just doesn’t work, right?

20:17> So the way I like to do SCRUM is that, again, you treat SCRUM team as, essentially, a startup; you give them guidelines, you give them all the tools that they may need to be effective and become hyper productive, and then you just have to get out of the way, right? I know it’s probably easier said than done, but you know, teams go through different phases of, you know, ‘storming’… ‘norming, forming, storming and performing’. But trust me, once you enable the team, once you step off, it usually takes 5-6 sprints for them to coalesce. But if you are patient, it actually pays off.

21:00> Ok… So my favorite topic; what SCRUM is not (Makes a pause). So a lot of conversations that I have in LA tech circles a lot of times it’s about “oh, we’re Agile, therefore we don’t do code reviews” or “we’re Agile therefore we don’t do architecture” or “we’re Agile therefore we don’t do testing” or “we’re SCRUM, therefore we don’t do X.” I hate that because it seems that a lot of people are using Agile or SCRUM as an excuse not to do certain things. And again I’m gonna go back to what is SCRUM and what it’s not. SCRUM is a communication framework; it doesn’t dictate anything that deals with your engineering practices, right? So if you want to have a strong engineering practice, then SCRUM as a delivery methodology is just part of the picture but it doesn’t dictate anything about documentation – whether you use Java docs or not, whether you do code reviews or not, how you define architecture, how you do QA – all these different things still need to be defined by your engineering practice as you’re building it, in fact, the stronger those practices are, the better quality of your code is. And again, SCRUM is just a part of the picture, and I hate when people use it as an excuse not to do things. I’m not sure if you actually heard that before, but I heard a lot in the past where ‘I’m not gonna document this code because we’re Agile, therefore we don’t do that. That’s…that’s crazy.

22:52> And similarly, SCRUM does not define business practices. One caveat here though I would say is that the business needs to change in order to enable Agile and SCRUM, and that’s because a lot of businesses are set up as command-control structures where there is this top-down approach, and, you know, everything comes down from the mountain, and there are the little worker bees that are doing the thing. If you want to scrumofy your organizations and enable these autonomous cross functional teams, it will take a lot of business process practice reengineering to get it right. However, SCRUM will not tell you that ‘oh, I don’t need customer service’ or ‘I don’t need shipping’ or I don’t all these different key functions’, right? You still need to think about those things. However, you may need to realign your business as a whole in order to enable SCRUM. Just to give you an example, in a traditional organization using waterfall a typical engineering manager can manage maybe 6 up to 10 people, right? In a SCRUM organization where managers are more viewed as serve out leaders, and they’re there to enable the team remove obstacles, work on engineering practice, they are no longer responsible for maybe day-to-day delivery, who’s working on what, checking things constantly, you know, an engineering manager can manage probably 20-30 people. So if you think about that, that’s kind of scary because that means a lot of people are gonna be out of the job, right? So, that’s also reason why SCRUM and Agile is such a scary thing to bring into organization, especially if you have been doing PMO for a long time and it was a very rigid command-control structure, because; N1, you know a lot of people will have to realign and change and we all know we don’t like change. But in order to be successful, it has to be recognized that, you know, you need to essentially alter how you are structured in order to have full adaptation of Agile and SCRUM in your company. If you don’t have that, then you have something we call a ‘gorilla SCRUM’; so there is some couple of guys in the corner that decide “let’s do the SCRUM thing” and they are doing this stealth implementation in one department, or two departments, but it never actually is supported from the top and those are some of the most difficult deployments, usually those are very-very political because you have existing PMO in place and you’ve got project managers that are now very scared of their jobs. So I am not sure if you’ve ever been in an organization like that. It can get pretty nasty. I can give you an example; I was working for a company where engineering essentially decided to go Agile and SCRUM and there was huge push back from PMO but we did it anyways and we’ve proven things from metrics. So we’ve actually showed 4X delivery improvement, right? And after six months we were doing not two teams but five teams, and after a year there were 10 teams, and after that the PMO was disbanded and we established Agile office and 27 project managers were no longer there but we had 4 SCRUM masters. So that’s an example of how sometimes it goes. And I don’t want to paint it as a scary thing; I just want to say that when you are adopting SCRUM, you can go a couple of ways about it. The best way is if the company adopts Agile and SCRUM from the top-down, right? Starting with the CCO and all the C suit, getting training, getting them…their thinking realigned, right? 

**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


Go to:

Part (2 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Part (3 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Part (3 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Posted on July 22, 2014 by Grindr Team

Part (3 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

1:00:06> OK, very quickly, a trans (changing the chart). Talking about work capacity, velocity and actual commitment. That’s a very interesting chart because you can tell that the team was becoming very hyper productive. Their work capacity was steadily increasing, it was very nicely matched with velocity and they were in-line with commitments. Then they kind of faltered there. They have a period where they had a sprint where their work capacity was higher than velocity, so obviously something happened there. And then they did another push and then just kind of wheels came off the wagon. There are interesting conversations that you can have with, let’s say, executive management about well, what actually happened. Maybe there is a root cause in the business, maybe changing priorities, too much pressure… I mean there are a lot of causes for this. But now you have metrics, you can actually show, you know, if you do this to my engineering organization, this is what happens (pointing at the chart). We had a nice trend, everything was going great, we were hyper productive and then you did these things, and that resulted in that, right? (Pointing at the chart again) And now you are not talking about feelings, this is not your personal feeling; those are metrics. And people respond to metrics, especially executives. So that’s example.

1:01:34> And here is another example (Showing a new chart). So that was another team of mine that was going through a lot of storming and formation and they eventually recovered and they started increasing nicely that the numbers came in line and the commitment with capacity and velocity kind of stabilized. But they were going through a lot of interpersonal issues on the team, there was a lot of fighting with the business, there was a lot of stuff related to requirements not being ready, or business was saying that it’s ready that we have all the assets, the assets were not ready… And that resulted in essentially this graph (pointing at the chart). So you can tell that it was all over the place. Usually what happens, you know, if people come to you and like “Lukas why are so many people quitting on your team?” You kind of “OK, let me show you. This is what’s happening.” (Pointing at the chart) And when you have a roller coaster like that, this is very unstable work environment sometimes. Ok, I don’t want to take too much time, so let’s go quickly to Elizabeth and maybe we’ll answer questions right after. (Talking to Elizabeth)



**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


1:03:04> Elizabeth Tarabishy: Hi there. I’m just gonna switch over real quick.

1:03:08> Lukas Sliwka: So, Elizabeth is going to talk about mechanics and how we do it inside. I showed you examples from my past, I talked about some experiences, and Elizabeth is working with teams [inaudible] so she has a very different perspective either.

1:03:29> Elizabeth Tarabishy: Can you hear me? Yeah? Hi! (Talking to the camera guy) I’ll turn this on. Can I move yours? (Talking to Lukas)

1:03:46: Just bear with me here. I can’t use my hands so I’m gonna be driving. So how is everybody? Good? Yeah? I see some smiles. So everybody ready to go home? Yeah? No? (Chatting with the audience, smiling)

1:04:08> Ok, so as Lukas mentioned, I’m gonna go through the daily mechanics of what we do here. And I just wanna talk a little bit more about what Lukas said about, you know, some organizations saying that they are practicing SCRUM and they’re not really. They think that when they set up a month sprint in JIRA, that they are practicing SCRUM. This is not SCRUM. So, you know, there is a big difference there. I’ve been in some shops that are trying and they are trying to get there. They hire an Agile coach maybe once every couple of months or something, and they bring them in and there is a small reset but what we reset with Scott in this shop was really good because I think that, you know, it pushed us in a really good direction. And we are doing things here that a lot of shops aren’t doing. And in fact the RoboSCRUM, trademarked sheet that Scott created, it’s RoboSCRUM 7.0. I think you said there is a handful of people using this particular spreadsheet. So just a little bit of a background on this. You can go into set up. What I’m gonna show you is what I use as a tool on a daily basis to gather metrics to help see what’s going on with the teams. So right here, there is a nice drop down at the beginning where you can pick your sprint length. So we’re in one-week sprints, and then just to go into the dynamics of the sheet. What we do is we list our SCRUM teams in here. Right now we have our SCRUM product owner, I go in there and then the delivery team goes in there. And then at the beginning of the planning you ask your team “Are you gonna be present the entire time?”, and you know you put here whether they are going to be in or out of the office and that helps out a little bit. And then in the next tab this is your sprint backlog builder. Now as the Chariot too, if you go to Scott’s website, if you go to, there is a spreadsheet there, but it’s not the “crème de la crème” sheet that you’re seeing here. It may be a little bit different; this is the Cadillac sheet (laughing), has all the nice belts and whistles. So it may not look exactly like this. So some of the changes that I’ve seen in the progression of the sheet is that this is your sprint backlog builder and what you can do here is in sprint planning when you are doing assessments of what you wanna take on, this is our sprint backlog ID number, this is basically our Jira number or ticket number. And what we do is we kind of put the votes of each individual team member in here and then that will give us the average and we can see, you know, who voted what on that particular… in planning on that particular task.

1:07:43> And then there is also this little daily stand-up votes, ok, I’ll get into the daily voting in a minute, but this is a nice little convertor here. Say for example you have 14 members and they are all giving a vote, they are flashing cards for that particular achievement for that day in the daily stand-up. This is a nice calculator within there, neat little feature that Scott put in there.

1:08:12> Ok, so a little bit more about gathering the metrics for SCRUM. There are two ways to do this. You have your set number or your planned number you come up within planning of your particular task. Say for example, something’s 8 points. And then you get into your daily stand-up, which in this shop we’re doing daily voting. So how the daily stand-up is run? If before the questions you’re asking the team… well, the team is actually talking amongst each other about what they’ve achieved for the day, how many points that achievement was worth. For example, one developer may not have worked on a bit; somebody did some QA on it. So the team collectively takes a vote on that person’s achievement for the day. And they talk about, you know, do they have any blockers, what they’re gonna achieve for that particular day. So, anyway, back to the voting, they vote on, you know, the achievement they had the previous day. So we take the votes, for example, in here the sprint backlog IDs, these are the two Jira tasks that we had. These were planned because they were planned in the planning period. Now in this particular dropdown too, if there was a task brought into the sprint, you can pick the adopted work here as well. But these particular tasks were planned; here is the estimate, and then this is because in one-week sprints, this is day 1 through 5. And then this is what the team voted on collectively each day. And what was the team doing is, like I said, they are flashing the cards, you could have 14 members but then I take the average of that number and then I put that in for the vote for the day. And then there is the decision. If product accepts this, if it’s QAed, and it meets the product’s, you know, expectations, it could be accepted on a certain day of the sprint. So, along with this, you can see the trans here (shows on the chart), for example the surprise work is the adopted or found work; we have some… the velocity metrics here, the work capacity metrics are in here, and this is only for 9 sprints. And then we can go into the scale. This is a pretty neat section in the spreadsheet as well. This shows us what we are really good at, you know, estimating at. For example the team is; they’ve estimated some 3s, no 1s or 2s, they have a good number of 8s, some 13s, 21s, 34s and 55. We have nothing 89 and above.

1:11:30> And this is the actual metrics (changing the spreadsheet). For example the product owner will look at me and say SCRUM master – or SCRUM mistress, as the CO has termed me (laughing) – he says, “SCRUM master, what was our velocity for the last sprint?” So take a look at here, I say “Ok, our velocity was 5,5 for sprint”. So then that gives him a good gage of, you know, how much he should bring in from the product backlog into the sprint backlog for the sprint. Because he feels confident and the team feels confident that they can probably gage that much for the sprint.

1:12:12> (Changing the chart) And here is the work capacity and the focus factor which Lukas talked about, the adopted work, found work… All the good stuff is in here.

11:12:20> Then here is the charts, and this is a pretty neat page, because you can use this during planning to bring up some charts to show or demo with the product owner. But this tells you, like, you know, gives you a glimpse of what’s going on during the sprint. So every day I hang the bring-down chart on the board, so if anybody wants to go by, they can see what’s going on for the sprint, what was accomplished. So this gives you a pretty comprehensive dive, you know, into what’s going on here inside the sprint. This particular sprint is not over (Scrolling down the spreadsheet), it’s still happening, so that’s why a lot of these are not populated at this time. But if I switch into another one here, this might have a better chart… (Pausing and looking for the charts) So for example, something that came up today was how we are doing with our predictions and our actual velocity. You know we’ve been trying to get better at, you know, predicting and pulling our velocity numbers close to that prediction. And this is where we were at the close of this sprint. So, I think with this one and with sprint 17 we were pretty much dead center with that. So also with proper SCRUM you can make changes within the environment to… during the retrospective, you can look back at the metrics and you can say “OK, let’s see what happened here.” And then you can, you know, go further into that. For example, one of our problems was a bundled release, was preventing us from putting something out. And we did a deep dive into that and when you remove these impediments, you can get better at predicting and you know, going forward and planning out your sprints.

1:14:50> And then here is a neat little chart that shows the history of success at scale. This is how good the team is, how good or not so good the team is at voting on certain things. For example there are 5 pointers, 8 pointers, 13 pointers… The green means they got this dead on; they were very good at their estimating for these. Now this looks pretty equal, we have some work to do but it’s a work in progress and we’re getting there. And that’s pretty much it for the chart. (A question from the audience) [Inaudible]

1:16:16> Lukas Sliwka: Yes, sometimes, but what you’re describing is more making sure that the work that you accepted to sprint needs certain criteria, so it’s actionable, right? [Inaudible] We had a wonderful product owner who is really very good at working with us, making sure that everything is defined well, broken down correctly… [Inaudible] because of tech death. And I can tell you it’s primarily caused by the fact the team is unwilling spend the time, open their laptops, do the necessary sprint planning. And that’s the conversation that I would have with the team using metric and observing how they do it. Because if you are constantly not estimating correctly, if you are constantly missing sprint commitment, you are constantly discovering “gotcha”s, your sprint planning takes 45 minutes and no one opens the laptop and the code, then we have a conversation. So my expectation from the engineering management is that the reason why we dedicate so much time on sprint planning and holding these practices, is because we want to give the team the time to come up with architecture, decompose work, take it out of the risk tech death, whatever conversation needs to happen. I mean we are dedicating half a day for this… Sometimes a day. So that’s a lot of time to plan. (A comment from the audience) [Inaudible] Elizabeth Tarabishy: [Inaudible]



**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


1:20:34> Lukas Sliwka: I had an example from another company where the team was constantly, essentially, working on large user stories, that were not decomposed and it’s really not a good SCRUM practice. But after a while – because they were really not willing to break things down, we got some problems with the product owner at the time also – we essentially made a rule in engineering saying that anything… you cannot have actionable user story greater than 21. For that particular team. And that makes sense to them. But it’s not a good practice, you should not do that. (A question from the audience) [Inaudible]


1:21:15> Elizabeth Tarabishy: (answers) [Inaudible]

1:21:40> Lukas Sliwka: The team has gotten better, also the product has gotten much better, so there is a lot of kind of mashing together that had to happen through all these different disciplines. Also people got accustomed with code more, so overtime planning gets faster, estimation gets faster. Elizabeth Tarabishy: [Inaudible]

1:22:15> Lukas Sliwka: Your question was specifically ‘do we see a correlation in metrics between the length of planning session and accuracy of estimation’, right? And I can tell you that I don’t see that here yet, because we haven’t been doing that long enough since the reboot, but I have seen that in other companies when you can actually go back in metrics and say that “Oh my God these guys, you know, took half an hour and then the whole sprint was off.” So, I mean you can draw that correlation but there is… yeah, I mean, there is some noise there too, because there may be other factors impeding the team, rather than just, you know, they may not follow the invest principle correctly and they are actually accepting work that’s not defined well.

1:23:13> Elizabeth Tarabishy: [inaudible]

1:23:34> Lukas Sliwka: So I can tell you guys, this stuff is not necessarily sexy. If you are an engineer you just wanna get in there and write code, right? But at the end of the day if you are trying to set up a really-really strong engineering organization and enable innovation and enable all these different things that are buzzwords these other days, it comes with a lot of hard work, and the reality is that it doesn’t matter how good your architecture practice is, or it doesn’t matter how good your QA practice is, unless you’re able to bring them all together through a good Agile office, practice and delivery, it’s not gonna work, right?

1:24:26> Lukas Sliwka: Any other questions? What’s up? (A question from the audience) [Inaudible]

1:24:44> Lukas Sliwka: So the way I’ve done it – and I’m sure there may be a better answer – in my previous engagement I essentially looked at how different teams of certain make up performed, and having those metrics I essentially used that as a forecast model. So, to give you an example, I had four teams in India and I had metrics on how they performed, and then there was a question, you know, ‘can we just add two more teams and get it done faster’. And I could give some of that answer because I could say, ‘hey, well, we can spin up that team and gain certain velocity’. But then we also had a conversation about what does that mean to Agile practice and communication and making sure all these supporting practices work. So there was a diminishing return. But, that’s how I did it. I just kind of guessed. (A question from the audience) [Inaudible]

1:26:04> Lukas Sliwka: So one things that’s important to mention here is that your forecasts in terms of the immediate execution road map is as good as your groomed backlog, right? So the longer your… the further the horizon is in your backlog that you were able to actually groom as a team, the more accurate you are. But the reality is that a lot of things change in the company so if you have 4 to 8 sprints vote of work actually groomed by the team that’s very-very good, right? And that’s your immediate horizon; beyond that you need to start using estimates. (A guy talking from the audience) [Inaudible]

1:27:28> Lukas Sliwka: That’s awesome, that’s great to hear, thank you. Yeah, I mean SCRUM and Agile is only part of the equation, there are, you know, I talk a lot about these things about Agile practice, so if you look at series what we’ve talked about, we talked about automation, code review, code quality… there are so many different parts of engineering that you must do correctly in order to enable a really strong engineering team. If you are just doing SCRUM correctly, that doesn’t mean anything, right? There are a lot of different things that have to come together. That’s why there isn’t that many good engineering shops that people want to work at, right? There are companies that got that secret sauce right, but even them, you know, it’s not all the time, right? At the end of the day, you know, you may think that you can systemize things, you can come up with the process and the templates and you can just put people in boxes, at the end of the day comes down to the individuals. That’s why SCRUM is so powerful because it’s a collaboration framework; it’s very individual centric, focus on the team working together. So I can tell you that part of our success is not only application of these different good engineering practices but also hiring the right people. So if you were to compare who was here a year ago, none of these people are here anymore. (A question from the audience) [Inaudible]

1:29:10> Lukas Sliwka: We have them every month, so once a month. (A question from the audience) And what is the motivation that you do this?

1:29:19> Lukas Sliwka: A couple of things. So, one thing that I was astounded by when I started here was the sheer, the volume and complexity of engineering problems that this company is solving. The app may be simple but at the end of the day, you know, to scale Redis cluster to process 110000 queries per second is not easy, right? To process 5000 transactions per second is not easy, right? To have a snappy response, to serve user base in over 190 countries... So this company is truly solving really hard engineering problems. Yet, I was really upset when I started it that there isn’t a line of engineers trying to work here. Because my opinion is that if you are in LA area and you wanna do solve some true hard problems, then come and work for GRINDR. So that’s my motivation. I wanna tell people what we are doing, I wanna give the word out and say hey, this is what we are doing, this is why, this is a strong engineering shop, we’re building things, this is not what it used to be a year ago. So I’m shamelessly saying hey, waving the GRINDR flag and come see what we are doing. So obviously there’s part of that… - Yes, thank you (laughing at a comment from the audience). But also a big part of that is that I’ve been going to a lot of tech talks and there is a lot of focus on technology, there is focus on little latest things that just came out like “look I’ve built a prototype”, that’s not really interesting to me. What’s interesting to me is how do I enable company to have very strong engineering shops, to enable innovation. So if you look at theme of our tech talks, we always frame it from a perspective, you know, how does this relate to me being a strong engineering shop and enable innovation. How do I do that? How is Google able to build something like Google Maps in their spare time? I want to do that. Not on that scale obviously, but I want this place to be able to solve things that no one has solved yet, right? So right now we just are putting that foundation, we’re realigning things, we are making sure that our day-to-day business is taken care of but at the same time we are building those strong engineering practices. So in six months I can focus on, you know, image recognition and processing technology to do, you know, recommendation engine, right? That’s what I really wanna do. You know, profiles, and pictures and multi photo and… (Waving off) (A question from the audience) [Inaudible] …So, this is my question, how do you define ‘done’?

1:32:50> Lukas Sliwka: So a very-very big part of SCRUM practice is agreeing with the team what the definition of ‘done’ is. So there is a list of things and if you go into that room (points out the direction) you look at the board, each team has listed what the definition of ‘done’ is, right? And the combination of things like being approved by product owner and meeting our expectations, but if you want to be a strong engineering shop, then you can also build in into that definition of ‘done’ you know, things like code review, peer review completed or test cases reviewed by development, or documentation, right? And the key is that the more these things you measure through continuous integration, the better you are. So things like whether… I can check automatically whether you are contributing to the code base classes without documentation because we are actually calculating the documentation density. And if that number goes down, then I’m gonna fail the build and everyone is gonna have no ‘why’. And I am gonna be like “Oh, you’ve committed this code and there is no documentation… Baaad… (Teasingly)

1:34:10> (A question from the audience) So the tests, that all is considered as part of being done in your eyes, right?

1:34:17> Lukas Sliwka: That’s correct. So if you commit to test driven development, then you measure that which means that you measure the code coverage every time you’re checking a class; the code coverage is going down, you fail the build, right? And it’s an agreement with your engineering team, hence agreement with the business as well. So it’s my job to sell a lot of these things to my boss and tell him, you know, why are we doing this, right? But the thing is that over the six months we reduced crashes by 5X. So, I actually have now metrics to go “Hey, we’re doing all these things so this is not smoking mirrors, it actually works.”

1:35:03> Elizabeth Tarabishy: [Inaudible]

1:35:34> Lukas Sliwka: Alright, guys, it’s late, everyone wants to go home I guess. It’s been fun, thank you so much. We are doing another tech talk in July; we will be showcasing our automation framework, we we’ll be actually showing all the work that Bernadette and her team has done to make sure that across Android and IOS platform on daily basis we are actually writing these automation tests. So this is going to be done using simulators for now, but we’re also working on the frame that allows us to execute in a cloud of devices. And we’ll showcase that also in the future. Cool? Alright, thank you guys! (Audience clapping)



**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


Go to:

Part (1 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Part (2 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Part (2 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Posted on July 22, 2014 by Grindr Team

Part (2 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

27:12> And that kind of goes – SCRUM does not define org chart but it definitely influences it.

27:21> And also SCRUM doesn’t define a company culture, again it’s just a communication framework but it very much influences it. So we have to be very aware of that.

27:34> And going back to my previous points, SCRUM cannot stand alone. So SCRUM needs these supporting practices to be in place to be successful. And it also needs support from, you know, the whole ecosystem to do it right because at the end of the day SCRUM and Agile is very hard to do, it’s not easy. I mean you are asking whole bunch of strangers to highly collaborate. You’re expecting QA guy to work with that guy and that guy to work with the front end guy in the same team and so far they’ve been very protective about their turf and maybe they’ve been communicating… they are sitting beside each other but they are communicating through comments via JIRA, right? I have seen that too. Or you’ve got people sitting at the same table and they’re skyping to each other because no one is talking, right? Yeah, that’s crazy. When I see that I go insane.

28:34> Ok, so let’s talk quickly about successful SCRUM implementation. I’ve already touched a couple of these points. So from my experience, if you want to do it right, the best approach is to actually (1) have executive buy-in. And that’s in contrast to ‘gorilla SCRUM’ which is essentially a team or department decide “You know what, we are tired of these things, we are gonna implement Agile” and they try to do that but they kind of do it as a cover thing. And there is this constant friction with the PMO because they are doing Gantt charts and they are walking around ‘what are you working on, what are you working on’ and they are like “Well, I can’t tell you, I’m doing SCRUM”. So that’s one thing. Another thing that’s very-very important I cannot highlight that enough is you need to (2) retain a qualified Agile coach. And I know that’s an investment, but I’ve seen it; if you think you can just go to SCRUM master training or product owner training and come out of that and magically be enlightened and do it right, then that’s not gonna… the reality is very different, right? You actually have to do it, you have to see it done in practice. There are people with different levels of certification but hiring a qualified Agile coach is a key. So we’ve been very fortunate that Scott (pointing at him) actually had time in his busy schedule and he’s been helping us to reboot the Agile practice here. So the number 3 is hire a qualified SCRUM master. These guys or gals are not easy to come by. There is a lot of people out there that have CSM on their resume, but if you poke a little bit deeper, you know, they just took some course two years ago and ever since they’ve been doing something completely different, right? A qualified SCRUM master is an extremely difficult role and I am sure Elizabeth is going to share some of her stories (gives a laugh). But, you know, you have to be a psychologist, you need to be a technician, you need to understand technology, you need to understand human behavior; there is just a lot of different things; you need to be very pragmatic, you have to stay very cool, because there is a lot of friction sometimes on the team. And you have to be able to extract yourself from all the fray and still make sure that the rules of the road are followed while gathering metrics and answering to executives about like you know “when is my stuff gonna be done?” So that’s not very easy.

31:32> And I don’t think Scott would agree with the 4 but I have actually used Kanban or SCRUMban as a gateway drug. I… We’ve successfully rebooted some teams with SCRUM but that was purely because Scott was there on side and he was helping us. And when he was not there, I had… I think 6 months to 9 months we actually had to carry the torch and deploy SCRUM to another ten teams and what we ended up doing is that there was a lot of push back from business, there was a lot of push back from the developers, so what we ended up doing was ‘ok, let’s do this Kanban thing or SCRUMban’ and kind of slowly introduce certain practices as people go and get used to. So you won’t get that hyper productive team very-very fast, right? But in a very political environment it will give you chance to train people and actually prove through metrics the value of certain things.  

**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


§2:41> Ok, and another thing that I wanna share is; don’t expect hyper productive teams in your graphically distributed environments. And this may not be very popular because seems that everyone is gung ho about going nearshore or offshore, or distributed and ‘I wanna work from home in my pj’s’ and all that good stuff. So my advice is don’t do it. Don’t ever do it. There is a workplace and there are seats, there are workstations, butts in the seats, people collaborating at the desk, ideally sitting in the same area, that’s the best way, right? I know that’s utopia, because in today’s environments it’s very difficult to hire top talent and you need to go to the next state or somewhere else to get the talent that you need. But if you do that, do not expect a hyper productive team without a lot of effort. So we’ve achieved very high productive teams in the past but what that meant is that, you know, for each team there was a remote. I actually had a guy, who was flying in to on-sight every month, and they were rotating, and there was this telepresents thing, a lot of money spent… At the end of the day you will never get the same conversion, you will never get that 4X, 5X, 7X…

34:15> And then the last thing that will leave me to metrics essentially, you know, you can use metrics to bridge the gap between traditional PMO and Agile/SCRUM. So PMO is very metrics driven, they’ve got these Gantt charts and man-days and man-weeks and all this other stuff. And unless you are able to measure your progress, measure your team and start forecasting when you can actually deliver on projects, you’re in a very difficult spot, because at the end of the day everyone wants to know when you can get the stuff done.

34:50> Ok, so let’s talk about metrics and how to measure SCRUM. I took a photocopy of a voting array that is used by our Android team. And as you can tell we are using Fibonacci; I’m not gonna talk about Fibonacci and why use Fibonacci, that’s a separate topic. You guys can read up on that if you don’t know. But at the end of the day, Fibonacci allows me to essentially assign a measure of complexity to a user story, right? Why would we use Fibonacci vs man-days or man-hours? We are terrible in estimation in time, as people, I mean we all know someone asks you “When can you get this done?” you say “In 5 minutes” but two days later you’re still working on it. But we are very-very good about comparing things, right? If you look around the room and I were to ask you to describe why this chair is similar to that chair, you can very quickly tell me why. Or why this desk is similar to this other desk, right? We are very good at that concept comparing things. So what we do essentially you allow the team - through sprint zero - to work through a body of work, some user stories, and at the end of that sprint zero you look essentially at what was accomplished. And you’ve got through the exercise where you pick something that we call a keystone. And a keystone is essentially a user story that from that point forward is used as reference for that team for either number 5 or 3 (Pointing at the chart projected on the wall). I mean people are different in that regard but what we usually do is, ok, find something that’s the easiest and you go through an exercise when the team actually defined why it’s the easiest and they list something like ‘OK it’s a simple algorithm and we are not writing a new algorithm’. So there is a whole bunch of things that the team needs to agree why this user story was the easiest and then we just arbitrarily say OK, from that point forward this is a 5. And then the next time you’re estimating, then you say OK, compare your work that you’ve just done against the keystone. Is this twice as complex? Three times as complex? Four times as complex? And overtime you essentially come up with this comparison user stories that you can essentially assign to these numbers, and that simplifies your voting from day to day very quickly, because now the team knows that 5 is this user story, they can go back, they can look at the code, they can learn; 8 is that user story, 13 is that user story (Pointing at the numbers on the chart). So now we’re business not thinking about time, we are simply comparing one work to another work; it’s like comparing one chair to another chair. So that’s how we measure SCRUM here at GRINDR, and that’s how I have done it… I have seen it done very effectively in other places.

3:17> Any questions on this? (A question from the audience) [Inaudible]

38:23> Lukas Sliwka: It goes infinite really. That’s a good question. So when you get into some of the other metrics, there is a metric that Scott came up with that measures accuracy of estimation, right? So overtime you can actually see which user story, which, I’m sorry, story point they have the most success in terms of being right. And then you can say, ok, well, I can tell that, you know, every time you guys are starting to size something out 34 or 59 or 89, you’re really not accurate. And it kind of makes sense, because what happens is that as you increase the size, the complexity gets larger and larger and people are having trouble giving a true estimate. So as you start measuring the stuff, you can actually see that usually people are very accurate around 5, 8, 13s, and then as it goes larger, it becomes a little bit harrier, right? One thing here to note is that a lot of times you hear people in Agile organization say “This team had a velocity of 100 and then this other team had a velocity of 200, therefore the first team sucks”, right? And you cannot do that, you cannot compare velocities between one team and another team. And the reason why is because velocity is essentially group thing for that particular team. Only they know what 5 means. Only they know what 8 means, right? (Pointing at the chart). That’s why you can’t say this team has a velocity of 100 or 200 or whatever and you cannot compare that.

40:20> And again that goes back to the fact that in order to be as accurate as possible, you essentially come up with this keystone, you come up with the story board array of user stories that this team knows very intimately therefore they can size their work. You may ask, well, how can I compare teams? How can I align teams and come up with timelines and all this other stuff? We’ll talk about that. (A question from the audience) [Inaudible]

41:00> Lukas Sliwka: It’s three times the effort. So, you wouldn’t talk about time, right? It’s a measure of effort for a team. If you want to talk about time, the only time unit that I would suggest you ever talk about is a sprint length. So if someone asks you how long this thing is gonna take you to build, then you can come back and say “Well, the team has estimated it, we know our average velocity per sprint””, right, I can divide and then I can tell “Hey, this is gonna take us three sprints”. And then you can give them a date, if you want to, right? But if you wanna talk about time, talk about timelines and forecasts, that’s how you would do it. What’s difficult is that, you know, since every team has its own measure of complexity, therefore each teams have different velocities, different averages. When you are talking about forecasting and aligning work and being able to tell executives when complex project can be actually delivered, that means to be very-very good at having a product backlog that is being constantly groomed and your team should be able to groom at least three months’ worth of product backlog, right? Which means that your supporting business organization they need to have their stuff together to be able to produce that, right? It’s very easy to, you know, ideate for a year and then drop stuff on engineering and be like ‘I want it tomorrow’, right? So SCRUM kind of pushes that a little bit back on business as well because now we’re saying “Hey, you want us to tell you when we can get things done, well, show me the user stories, show me at least a good number of them, and then we can start grooming the backlog, we can start estimating and forecasting things.” It’s very unfair to ask a team ‘when can you get something delivered’ if they haven’t had the chance to decompose it and size it. Unless you wanna go back to, you know, architect and engineering manager getting together and spending three nights decomposing things and doing the tasks and then ‘this is gonna take us three months’ and then three months later you need six more months and double the budget… And you’ve got typical type of thing.

43:41> I can tell you I am not very good at history and statistics but I think it’s been shown that if you do SCRUM correctly, your estimation is around 80% accurate… If you do it correctly. And waterfall is 50/50. So it’s like tossing a coin at the end of the day. You might as well not do it. Scott Downie: Waterfall is 15. (Talking from the audience) Lukas Sliwka: 15? Thank you, Scott. So, 15 and 80%. I’ll take that. S.D.: Where did you get that number? L.S.: Now here we go (Talking with Scott and laughing) Here we go… So let’s do that. Again, Scott is available for questions, he’s also very-very opinionated, we don’t agree on everything, so that’s always interesting.

44:40> Ok, have I covered everything here? So, is it clear the notion of this basic, you know, notion of being able to define a keystone, the team now has a way to compare things, right? (A Question from the audience) Why don’t you just use like a simple 1 through 10? [Inaudible]

45:03> Lukas Sliwka: You could… You could… It’s just widely used. And I think the way the scale works is one number is twice as large, almost twice as large as the other one, so it works very nicely. But yeah, you can do that. If you wanna do 1 through 10, you can do it as well. (A question from the audience) [Inaudible]

45:30> Lukas Sliwka: Yes, so when you go to the grooming session, you want to always work in the priority order, right? Because what ends up happening is that at the top of the product backlog you always should have projects that are the most ready. So ideally that user story at the top of the backlog is actionable. Because it may happen that your team finishes early their sprint and they start looking for work, you wanna start pulling stuff from the backlog, right? When it comes from the sprint backlog, the priority is set by the product owner and it never changes. And the team is supposed to work in the priority order. (A question from the audience) [Inaudible]  

**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


46:18> Lukas Sliwka: A very good question. So yes, ideally you would want business to agree to have some sort of business value metric to prioritize things. So some people use return of investment, there are metrics that people use… the fact of the matter is I haven’t seen organization yet that actually use that metric very well. It’s usually a business asking engineering for metrics and measure the performance of delivery but not necessarily the actual business value that’s being asked to deliver. Which I also think is very unfair and I push back on business as much as I can because, I mean, if you are asking me for my key performance metrics, and I wanna know why am I busting my hump, why am I actually delivering, right? Why is this more important than something else, right? And that sometimes is very hard to answer because you have to do your homework, you have to do your metrics, you have to do market research, you have to actually, you know, work. (Laughing) (Laughter from the audience) (A Question from the audience) [Inaudible]

47:44> Lukas Sliwka: Good question. The fact that you have shippable product, doesn’t mean that you’re gonna make a life. So what we do - we actually bunch things up into probably 2-3 weeks increments and then we ship it. Ideally we want to submit every week, but as you know mobile development is tricky on IOS side a lot. On Android it’s easy; you can push versions pretty quickly. But on IOS you have to go through review and all that, so that adds to the cycle. So we try to bunch things up. And sometimes it doesn’t make sense to maybe ship business functionality without other things. And that’s also a very difficult conversation sometimes to have with product owners because they have this syndrome from waterfall days that, you know, “Oh my God, I got my spot in the queue, therefore I’m gonna throw everything including kitchen sink (giggles from the audience) into these requirements and I want everything because who knows when I’m gonna get a chance again to do some development.” And then the project runs late, and it’s you’re later and that stuff is absolutely… anyways… But long story short, you know, a lot of people are kind of trained and they are thinking, you know, they don’t understand that it’s ok to come in with ten requirements, go to development, ship four, and then adjust and never do the remaining 6 because there is no business value there anymore. And we shift it as a company to something more important. But it’s kind of this syndrome like ‘this is my project, this is my baby, I want everything done’, so it’s constant kind of… That’s why I wanna talk about that top-down thing. That executive management… everyone has to understand that in order… how to work in that mode and if you do you become an amazing company because you constantly are able to shift to market conditions and release things that are the most important to the customers. But you also need to have supporting practices to be able to measure that stuff because you need to have some way to say that this is actually more important and the question is how do you do that? How do you get that feedback from your market? OK, moving on.

50:12> OK, so we finally got to SCRUM metrics. Again if you go to Scott’s site, I believe he’s got plenty-plenty more. I just listed the ones that I used, this is my experience. Those are the metrics that I use (Showing a chart); the ones on the top I would use on weekly basis, and then the more you go down to the bottom, those are metrics that you would use less often, at least I use less often (Scott would argue with me but that’s Scott). So velocity, we talked about velocity. Essentially velocity is when you have a team working in a sprint; they accepted the work, all these user stories are sized, and as they’re going through the sprint they essentially complete these user stories in accordance to definition of ‘done’ – and that’s something that the team also has to agree on what that means – and usually that results in a demo to the product owner, the product owner accepts. The moment they do that, then those points are counted towards velocity. So, velocity is essentially a sum of all your story points that were delivered by the team and accepted by product owner, right? So that’s velocity.

51:40> Work capacity is a metric that counts all the story points completed by the team, right? So there may be a lot of work being done by the team during a sprint but only a fraction of that work is converted into velocity, because some stories may not be completed, they may be dropped, you might have started working on a user story that’s 21 and, you know, you abandoned it half way, but you actually completed 13 points of work. All that stuff accounts for, essentially, work capacity. So work capacity is a very interesting metric because it indicates overall capacity of the team, right? Now, here is where it gets interesting. When it comes to talk about team performance and measuring teams, right? That’s something I use every sprint and I actually a lot of times bring those numbers to retrospective to talk about teams.

52:50> So the top two metrics are in red because velocity and work capacity cannot be compared across different teams, right? You cannot say “Hey this team’s work capacity is 500, the other one’s 300, therefore, these guys are better than the other guys.” Again going back to the story array, that each team has a different yard stick to measure their work, therefore you cannot do that. However, the moment you start comparing velocity and work capacity and start calculating the ratio essentially how much of your work capacity you converted into velocity as a percentage of work, now that you have a metric to compare against team. And you have a metric that’s actually very useful; we call that focus factor. So percent of work capacity that actually has been converted to velocity is your focus factor, and the healthy metric is above 80%. So if your team consistently converts over 80% of their sprint backlog to velocity, then that’s a healthy focus factor. And that’s something that you can then start discussing with the team. If you see that the team constantly has a 50% of focus factor, then you can start question “Why are you guys not converting, are you all swarming the most efficient way on top priorities?”, do you have developers starting cherry picking work and hoarding work because it’s more exciting and they are not willing to work with other people, therefore, they are not as effective and efficient. You can start asking those kinds of questions and you can start watching team’s behavior, right? Or, another one is… nah, that’s enough.

54:45> Then we have adopted work. So adopted work is essentially the work that you can start measuring… that you can measure. Let’s say you planned for hundred story points in the sprint, and you completed everything and then you start pulling things from the backlog: that’s adopted work. So now you can actually measure that as well. And start seeing, you know, on percentage basis how much of adopted work per sprint a team can have. And it’s also used for conversation because if you see that a team has 50% of adopted work of the sprint that means they are under committing during the sprint planning. Then you can start questioning, ‘well, if you are adopting, if by half, midpoint of the sprint you’re pulling work from the backlog, that means you are under committing during sprint planning, therefore you are being extra-extra conservative, therefore I am not able to forecast and plan correctly, because you are trying to protect your ass’, right? So that’s a metric that’s also very useful.

55:59> Found work is something that I watch for very religiously on teams which is essentially if you estimated 13 points and then something became 21 points, that’s found work. The differential is found work, right? And a lot of times what I’ve seen in my experience it due to a couple of things; technical death, that’s unaccounted for or an unknown, and that’s legitimate. However, I would argue that if you do your sprint planning correctly and if you’re having actually effective sprint planning session, you have people looking at the code, talking about architecture, deciding who’s gonna be working on what… you should be able to discover these things, right? If you’re going through a sprint planning session, and no one has looked at the code, then that’s a problem, right? 56:55> And then there is accuracy of estimation. I talked a little bit about that which is you can actually tell how accurate teams are per each measurement; 5-8-13 then accuracy of commitment which is how accurate are we in making our sprint commitments, right? So those ratios can help you, if you are forecasting, if you are planning, if you need to know all these numbers and you need to deliver timeline, that’s long timeline, you can use these percentages to essentially pad or adjust your timelines. Or the number of sprints that you have to forecast for. 57:35> I’m wanna show you quickly some examples of what I’ve used (Changing the chart). This is not from GRINDR, this is from other teams. So this is an example of a burn down on steroids that shows you all these different things and it is a very-very good source of information. If you are just walking by a team’s SCRUM board, and you’re looking, you’re trying to get a glimpse how’s it going. there is a lot of information here. You can see how the actual burn down is going down. You can see what work is being reported day-to-day. Since we are talking about it one thing that Scott advocates, is also sizing daily what the team actually resolve, what kind of complexity they resolve day-to-day. So normally during a stand-up you would talk about what have we accomplished yesterday, do we have any blockers and whether we are accomplishing today. So those are the three questions. There is a fourth question that we ask which is how much that resolve complexity was worth. So you will actually see our team is voting day-to-day. So they talk ‘OK, this one guy I wrote this class and that class’, and whatever, and then the QA says ‘we wrote these test cases, we tested it, everything worked’, so they actually talk what they resolve complexity-wise and then the whole team would vote very quickly right there, right? And we would capture those metrics. So, anyways, that’s an example of a very healthy team. They have some production support there but it wasn’t enough to abort the sprint.

59:27> And then there is another chart I wanna show you which is this; which is obviously the team was in trouble, they were not delivering or resolving complexity over day. We knew by third day-fourth day of the sprint we were in trouble. And then they did a huge push on day eight and nine and delivered a whole bunch of stuff at the very end but they never actually resolved fully what was committed resulting with only 50% focus factor. So that’s an interesting thing to bring to retrospective.  

**** WE ARE HIRING **** is hiring for Senior Android Developers, iOS Developers and Principal Application Developers.  If you are interested in our careers, check out and email


Go to:

Part (1 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team

Part (3 of 3) Grindr Tech Talk: Using metrics to drive a high performance SCRUM Team