 This presentation is all about sharing my experience on one of the projects while working with the client. We tried out some innovative thing of not using StoryPoint and using StoryCount to track our project progress as well as to track velocity. And then in general, asking this question, if that worked, should we just start thinking in terms of whether we should continue using StoryPoints or should we use something else like what we did of using the Count of Stories completed in a Nitration? Is it audible? Okay, cool. So in most of the agile projects, the typical scenario is like this. You ask development team to get the estimate for the product backlog. What happens? The development team goes into a room, comes up with, puts some number on all the stories in the backlog and then comes out after like two or three hours, comes out with the estimate for all the story cards. They hand it over to the project manager or to delivery manager. Then we then spend some time coming up with a burn up and burn down chart so that they can track this going forward. When they do this estimation, I've seen issues where like people tend to put, they have this hidden pressure from the management that don't put higher estimate. We need something to be quick urgent and then you probably end up putting estimates lesser than what is the actual estimate for that particular story. So what happens is when you start, you realize that the estimates were wrong and then there's a certain pressure. When some story is taking longer time, the managers start putting pressure on the development team. Why this story is taking longer time? So I faced this issue in the past. Most of my team members who worked on this project faced this issue in the past. So we were thinking why we estimate and we got these answers. Why we estimate because we want to track velocity. We want to decide scope, how much we can pick up in an iteration and also to help prioritize stories for the product manager. So the product manager can prioritize stories for the iteration. And eventually it will also help in planning some religious. But is that the case? What happens? In reality, you must have seen this situation. The estimation takes so much time and effort. I've seen situations where people spend days and one and one or two days in just estimating product backlog. Then there is a tendency between the project managers and the delivery managers to relate these story points into number of days and then asking developers, okay, one point of story, why is it not done in two days? Why is it not done in three days? In some cases it's like a deadline. You said it's one pointer and it's been four days now. It should have been done in like two days. What happens is there's a lack of confidence in the development team. When you see that some smaller story is taking more time. And we saw that happening in the past project. So we thought, how can we avoid this? Can we do something? And we looked at some of the claims that justify use of story points. If you have seen that book, User Stories Applied in Micron, you have seen these claims. The first claim says why the story point allows us to change our mind whenever we have more information about the story. Okay, so what does that mean? That means if we get some additional information about a story and if it's a small change, we can definitely accommodate that in the same story. But if you see that it's a drastic change or if it's completely adding a lot of scope into that story, you end up putting more estimate or you end up creating more cards. But that can be done by counting cards as well, right? Like you don't need, story point doesn't tell you that that's the only better approach for handling this situation. So what we did, we used story count and it worked well for us. So the second claim which says that the use of story points work both for apics and smaller stories. Well, yes, you can have one point of story. You can have 12, 10 point of story. But 10 point of story, like how does that help? Does it mean that 10 points is like one point or 10 times? Or does it mean like 10 point or is like five point or two times? What is it? We don't know. So what's the value that we're getting by estimating apics? So this claim is itself is false. I don't agree with this claim. Third one, it says that the use of story points doesn't take a lot of time. Well, we saw that in the past that estimating one or two stories might not take a lot of time. But if you end up estimating a product backlog, you might take probably three hours, four hours, almost a day or more than a day. And this is just a guesstimate. It's not that it's a final number. I don't understand why people put so much effort and time in putting estimate on the story card. And eventually the project priorities change. Your scope changes. So even if you estimate like a long running project backlog, it won't help you. So why then use story point for estimation? The use of story points provides useful information about our project progress and the work remaining. Yes, it does. But then to do this, you need to estimate each and every story in your project backlog. You can't just have like five stories estimated and then based on that, you'll project something. And then again, the time it takes to estimate this much of work. So the fifth claim which says the story points is tolerant to imprecision of the estimates. Yes, I agree with this. But then it's not the only tool, it's not the only technique that helps us. Probably counting story cards will probably do the same thing for us as well. So and then the last claim which says the use of story points can be used to plan religious. I guess any estimation technique whether you use story point or use any other technique, it will help you to plan your religious. It's not that only story point help you to plan your religious. So if that's the case, then we thought if all these claims, it's not saying that story point is the only technique which will allow you to handle all of these cases, then why use story point? Can't we use something else? So what we did, we were asked to build a mobile application for an insurance company so that user can buy car insurance on mobile. The product owner was very keen to understand how much time, how much effort it will take to build this MVP scope. We decided to not use story points for estimation. But then what to do? What should we do? If not it's no story point, then how can we predict, how can we say that how many iterations it will take to complete this? So we knew that we wanted something simple, something which can help us to track it easily which will require less time in estimation. So we went ahead and started using story count. We said so what does that mean? We said we will measure the progress by measuring the number of stories completed in an iteration rather than using number of story points completed in an iteration. So using story count, how does that work? So what we did, we went ahead with the assumption that all stories are of the same size. How does that happen? You can't have all stories are of the same size. There might be some smaller, some stories might be of higher, some stories might be large. So how do you manage this? So what we did, we went ahead with the simple technique. We actually running and one week iteration. So what we did, we asked a developer to check quickly if this particular story text is can be done in an iteration. If you see the answer immediately as yes, you keep it aside and move it into product backlog. If you see a developer saying not sure, I don't know, no, then you know that that story needs to be split into multiple stories. And then you continue this exercise until you finish all your product backlog. So what we did, instead of asking the estimate, we just checked just the guess whether you know that this story can be done or whether what's your guess in terms of completing this in an iteration. And it took not more than two hours for the entire MVP scope. In the past, we spent at least half a day or more than a day or rather more than two days in estimating 100, 100, 100, 200 stories. So once we knew that there are like 100 stories, let's say, what we asked, we checked how many of these can be run in parallel. So we knew that out of those 100 stories, at a time, we can have three parallel streams of work. So based on that, we asked a dev pair. I'm sure all of you know agile velocity game where it's like a planning poker game. You ask people to find out what can be the projected velocity for an iteration. So we did the same thing, but instead of points, we asked them what do you think, how many cards can be completed in an iteration. Based on that, we got the projected velocity. So we used that information and we started our iteration one. At the end of iteration one, we just verified whether what we said in the velocity game was correct or not. So at the end of iteration one, let's say we said we'll complete around nine cards in one week iteration and at the end of week one, after our iteration one, if we came around eight to nine, we went out with, okay, let's go ahead with eight story count for an iteration. And using this formula, we calculated how many iterations it will take to complete this entire product backlog. So it's not a rocket science. We use the similar techniques what you do for story point, but instead of story point, we did use story count rather than using story point. What we did, so we re-looked at the velocity after second iteration, after third iteration and we adjusted our velocity accordingly. You do similar things when you use story points on any agile project. So we did the similar thing again. And in iteration planning meeting, instead of talking about how many points we should sign up, we just looked at the past velocity in terms of number of cards completed and use that for planning our capacity for the next iteration. If you see this, the Burnup chart, so you must have seen this in the past where you have your scope over here and you have your projected velocity and you have your story point count, the number of story points completed in an iteration. Instead, we used a story count completed to project our velocity and also the actual velocity. What we did, we also used something called a feature completion tracker to see. So if you see this, whenever the card was completed, we used to show that this card is done, we cross it and that helped us to give a single view of where are we standing in terms of MVP scope, how many cards are done, how many cards are not done. So there was no any other metric that we used apart from the story count. So just the Burnup chart and using this feature completion tracker to show just giving a single view for the product on where we stand today in terms of the MVP scope. How it helped? So it did help. If you look at what I said in the past, in this case because we were using count, we were not using story point. We don't have to worry about metrics and then converting and making sure that each story has a story point and then using that story point to track our project progress and all of that stuff. Instead, we focused ourselves in the IPM like in the iteration planning meeting to talk about what the business value that we're getting from this particular story and talk about how and helping everyone to have a share understanding of what we are building and how we are building rather than worrying about why this is a one-point or why this is a two-point or why this is a three-point. So we removed all that discussion and rather focused on making sure that everyone understands what we are doing. And that helped us in when we started working on that particular story because people had a lot of understanding about what they are doing, how they are doing. Definitely it helped for project manager because you don't have to worry about how to track the story point. That particular story doesn't have an estimate. Can we get the estimate? We missed out estimating one or two stories. You don't want to do that. You just have to calculate the story card and based on that, you can just plan your scope. So no one had to go back and relook at, okay, these are totals around 50 points. What should we do? How should we handle it? We just used the count and that helped us that resolved a lot of complications and issues that we faced in the past. We also were able to quickly handle any change in scope or change in requirements and better way to track change in scope. So if you see when we use story point, you have seen the issue where if the scope changes, there's a tendency to either accommodate the scope in the story itself or you end up bumping up the story point. And then you lose the track of where the scope change happened. Here you end up creating a new card and that's the easy way for you to track how much scope has changed from initial product, whenever you did the initial, when you had the initial understanding of your product. And it helped us because we were tracking it continuously without worrying about this story is not estimated. We need to go into the estimation session again because we have more understanding of the product. We just ended up creating more stories when we had more understanding of that product. More focus on completing stories which give higher business value instead of having a quick gain in story points. So I have seen tendency in project managers or in the team to pick up stories which will help you to get a better velocity. Rather because every story was same, every story there was no story point against the story card. What we did, we just looked at what story will give us the better business value or higher business value and we picked up those cards first rather than focusing on which story will give me higher story points at the end of this iteration. So that helped us. In my mind, if you look at how it worked, it will probably work for... This is just an experiment that we started. We did it for one or two projects in the past. I would like to continue going forward but from what I understood that it will probably work if you have more than four or five iterations in your project. You need to have a lot of trust between the product owner and the development team. In case you don't have, my suggestion would be to start with estimating the first release and then eventually you can build a trust and then start from... You can probably evolve your estimation process right from story points to relative sizing to story count. We also did... We also used something called cycle time to find out what are the bottlenecks in the project and how our work is evolving, is flowing through the development process as such. And use the cycle time analysis to find out how can we improve the overall process as such and reduce the development cycle. So it helped us. In a way, I will say that if you... You should stop wasting time trying to estimate a never-ending backlog. There's no evidence that will help you better than just using the story count for the number of stories completed in an iteration. Questions? Did you see that kind of behavior? I mean, is there a value in not the numbers but as a communication tool to kind of... So as I said, the differences? I agree. I did not remove that discussion. The discussion was still there but discussion wasn't more around why it's one point or why I think it's a two point. We just talked about what are the better approaches to build this functionality. What are we building? How are we building it? And why are we building it? So the discussion was more focused on delivering the value to the business rather than around estimation why it's one point, two point and all of that stuff. Does that answer your question? You can... So when we... We actually typically in ThoughtWorks, what we do is we do an inception before start of the project. So we come up with some stories and then eventually as we move on, you end up creating more stories when you get more information about a product. So you can create those... You can split those stories either before the iteration or you can do that in the iteration planning meeting itself. It's not necessary that you have to do it before. Around the same size and things like that. Because if you... Even if you have to break it down to an extent that you can go to the weaker stuff then it typically becomes the task which is eight hours, ten hours task, whatever it needs to be. So was that stories eventually looking like... Were the stories looking like tasks or the stories were really stories which had a clear criteria of acceptance and proof definition of that and stuff like that? All of these were stories. There were no tasks as such. We have... We've been using one week for an iteration almost for... I've used it for almost like three to four years now. And even when we were using StoryPoint, it's the same... That problem can occur even for the StoryPoints as well, right? All of those were stories... Why? There's a lot of value in doing that when... What is the value in getting the business out of it? When you break the stories, you also have to keep the business value which that particular story is going to tell you about. That problem can occur even when you use StoryPoint, right? Eventually you pick... You try to pick up stories which can be done in an iteration and you end up splitting the stories. So when you split, you need to make sure that as a BA that you are not... not compromising on the business value. You're doing what... There's like not using StoryPoint. There's no challenge. It's... The challenge is same whether you use StoryPoint or whether you use StoryCount. It doesn't change as such. You're doing StoryPoint distribution, right? And then you move to non-StoryPoint distribution but you started splitting the stories into smaller ones so that... No, I didn't say that... We never... We use big stories. We did... We had to split those stories because if you... What you do in an iteration, you pick up stories which can be done in an iteration, right? So you had to... If there are a lot of... If there are a lot of bigger stories, you split those and make sure that we have stories which can be done in an iteration. If you end up picking up stories which are big and can't be done in an iteration, you carry it forward to the next iteration and it just goes on. So the... Whether or not you use StoryPoint, the idea should be that you should split stories and make sure that that story should be completed in an iteration. The report goes into ensuring that stories are of approximately equal size. Not really. So... How can you say that, you know, if I finish 10 stories in student one and I finish only two stories in student one, that would not be the case. Sir, in your case, approximately the number of stories should be approximately the same. Yes, there will be differences. I am not saying... All stories have to be same, but the difference will even out over a period of time. It's not that... So initially probably you'll have some hiccups, but over a period of time the difference will go away. And my technique for using or splitting the stories was just get a quick guess. If you get a quick answer from the development team that yes, it can be done in iteration. If they think, if they say not sure, don't know, that means you have a scope to probably break down that story further. I mean, to deliver the entire story, right? Or just a development part of it? To deliver the entire story end-to-end, right? To deliver it, they test it and then deploy it to production. Is a story in this rate or not? And then you pushed some user stories for breaking them up. Yeah. Did it happen... Because of this, did it happen that you had some complex user stories or which, you know, big user stories left for the end? Because some stories are very difficult to break down. You cannot break them down. They are big user stories. So, yes, if some stories which you can't break, you need more information before you break right. So you just keep it aside and you highlight it to the product owner that we need some information. So what we do, if we know that there's a big story, we don't have a lot of information. You put a number saying it's a 10-point or 20-point, but eventually that's going to change. So we just kept it aside. We said, okay, we don't have any enough information. Probably in a week or two, we'll get more details and we'll try and break this further. So instead of calling it as an epic, we kept it aside. We knew that it's something that we had to work upon, but we did that by doing some analysis or investigation and finding out, okay, whether we need to split this, how can we split this and all of that stuff. So that means you need to start with the analysis, which I can add if you want to split that. So in that case, we will not be able to split it and if we do some same thing, I think it will not, like, I mean, it will not take the proper picture, right? It will be still big so that we could have completed only one story card because we were not able to split it. Not really. I had like two such stories which were like epic and then when we knew that, okay, we can't, we don't know how to split this. So we spent some time, not more, like, you do that whether you use story point or whether you use story count. If you know that it's epic, it's a 20-pointer, that means you need some more effort to investigate and break it down further. So it doesn't matter whether, like, it doesn't change much as from, like, using story count as a technique rather than using story point. That challenge will be there for a company, like, every one's story point, story will not... Yeah. reputation story. There's nothing like that. We just keep it in the room. Not analysis. We know that, okay, that story needs to be split further and we just keep it aside and then it come back again. It can come back again after once you split it further. Then you can, then again, ask that question, same question to the development team and check if, now do you think these multiple stories can be done, like, each of these can be done in an iteration? If they say no, then again, you need to split it further. It cannot be taken in this way. Yeah. So the same thing you are doing it with this approach is there. There's nothing different. Yeah. The question here is, it's related questions. What's the size of the team that you have? Definitely very different. I had three dev pairs around six people dev, developer development and like one QA. Electron decision, yes, we can do it in one week. So we ask, It depends. You can ask the entire team, but do not waste everyone else time. We typically pick up, like we ask two developers to just check and tell us whether it's possible. But is this, so the discussion, for the discussion around how should we do it, what should we do it, that discussion, you need to have entire team over there just to check whether it can be done or not. In an iteration, you don't need an entire team. You can have one pair or two dev pairs sitting and just confirming it. Experience question. Yeah. The other question is related to it. So there are four people. So how do you plan for that one week? So you say that if one person says I can do one story in one day and no, we don't do day wise thing. So once you start working, so you must be, you know, having some part figure in mind that after one week of split we would have so many Tory cards done. We did the same agile velocity game where we asked them look at these cards, tell a pickup cards which can be done in an iteration. So people went ahead and picked up some cards and we asked them, we did it multiple times and then on an average we calculated how many cards they think can be done in an iteration and use that as an input for the first iteration. And then whatever the actual velocity that came out of the first iteration, we just refined it and then used it going forward. We still have a developer and a tester and a tester automation network company committed to do one new story. So then in these games do you break it down further the story into your task? How does this It's up to the development team how they want to do it. I'm just talking in terms of the planning, how we plan, whether you, how you develop, you can, you have, everyone has a different approach to develop story, right? They might want to break it down into smaller task and handle the task each day or whether you want to do it, discuss it initially and then just get started. So the development team has different approaches and how they want to do it. So this is just a, this is just an estimate. Like we are just saying that we will probably be able to complete this. There is no commitment as such. We are just saying this is the indication. You can't just hold somewhat responsible that because you did not complete this, why did you not complete this? Can you tell us why what happened? Just an indication it should not be considered as an commitment from the development team that they will, they should complete at least five stories for iteration. Yes. Yeah. We are just saying that my limit is one story point and you are referring to one story point. Is it something like that? We can do it that way. It's not, if you want to, if you want to do it that way it's fine. As long as you, you don't spend time in estimation, it should be fine. So you have published this report, experience report on the site. So if you want to read it further, if you want to, read it further.