The story point is high level estimation based on complexity before the work begins on story while the hour based estimation is just more concrete estimation where effort is represented in hours. The amount of work a team can accomplish during a single sprint is called Velocity. It is calculated at the end of Sprint by adding all the story points which are done-done.
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of theSprint by totaling the Points for all fully completed User Stories
Now the question is how does story points relate to time and this is certainly one of the debated topic among sprint teams and I see confusion all around. I heard from individual team members many a times that story point can never be related to time in any way. One cannot say 1 story point equivalent to 2 hours or 5 hours or any other number. The second statement is right while this creates a notion that story point has no relation with time. When you have 3 story points, it could take 3 days or up to 50 days. This doesn’t seem right and this is actually not RIGHT. “Whatever time it takes is fine after-all one is putting on effort” effect is what visible .
The reality is, the story point states EFFORT. The estimation for team member X can be 10 hours for 3 story points while other it could be 20 hours. The moment you say effort, it is size. But the size is relative. Hence it proves the point that it is not exact hours while it’s relative hours. The estimate is for team and they should be able to say what is the biggest size in terms of story points can be picked which would be done in sprint. Moreover if we say, team velocity is 40 story points that means we can complete 40 story points for this team in N week sprint.
If one doesn’t want to relate this to size at all, then I suggest them to stop doing estimation as in that it case it would be just waste of time. Typically a story point suggest min and max time which might be taken to accomplish that story. For instance 3 story point for team P means effort between 3 and 5 days. It could be plus or minus but the point I have is to have some indication with respect to size.
I have seen individuals just change the story point for a given story if they can’t complete the same in stipulated time. I understand the estimation was not done right or probably we might not have done estimation but adding/changing story point or hours post the work is being done is pathetic. It completely wastes the time spent on estimation and further we lose all the value gain with estimation. This practice is primarily meant for inflating numbers to have better reports. This MUST be stopped.
I have been often asked that the team is not able to predict well because they are new or may not be competent enough to find the right story points. How should we handle that as it is important to be predictable as you can’t run the business in vacuum? When your boss or business ask how long it takes to complete the effort, you still have to answer probably by looking at release planning and estimation. This shows another point why we have to relate the effort to hours (Not the exact) and here min and max does the job.
As we are talking about story points, there are many teams who would just add story points to story while for individual tasks they don’t assign hours. The burndown chart in that case is driven by task (Task based or hour based) which is in a way weird because you suddenly see ups and downs. The whole value of one of the most critical artifact in agile is not being materialized. The planned and remaining hours is important in individual tasks.
There is enough motivation I have to write this article as the whole intention is to answer the questions which I have been asked multiple times pertaining to sprints I dealt with.
Some of which are listed below but not limited to
– How can we ensure sprint success?
– Should we do more or less?
– Why continuous improvement?
– How can I be successful? How can I grow faster?
– How to get better at estimation?
– Am I following the right set of processes?
– Is pairing good and how should we pair?
– Am I being heard? Should I challenge people? What if the team is very senior compare to me?
– The standup happens in the evening because of the offshore and onshore model? How to make it effective?
And the list is endless.
Let’s assume you are already in sprint cycle. One of the important questions is how do you provide an estimate for items which are already prioritized for sprint? The majority of newbies teams with limited exposure to agile struggle due to unknowns during mid-sprint which was not accounted for. The estimation might have given with many assumptions. The predictability is the biggest concern in most agile teams. One of the easiest ways is to pre-groom stories well in advance. Typically for two weeks sprint, I encourage the team to spend 10-15% of time daily during the second week of a sprint to get as many details as possible for next sprint stories, create tasks, identify dependencies, quick spikes to find out the feasibility.
The typical myth most people have that we should be adding only tasks having business values while it might be a look good factor for product owner but from a developer standpoint, this is something we should avoid. In addition to functional and non-functional requirements, a team should add testing, documentation, and everything that they would work on as a task. This given better clarity and sharing of work.
When you constantly spend time in grooming next week sprint story, you are very confident how much worth of work you can do it in next sprint when you get on to sprint planning as your estimates are good enough with confidence that what you are going to build. As this practice continues, there is a point which comes approx. in 3 to 4 sprints where the team doesn’t even pick a work which is not clear.
In summary, when a team starts with sprint, during the planning meeting, everyone talks about stories and tasks (Tasking is done). The goal is to add/remove items might not have been considered and provide estimates. The commitment is made with lots of confidence. You can never avoid unknowns while the chances of getting it reduced significantly increases.
Just to prove above point, once I have enforced SRS (Software Requirement Specification) in agile where it must have to be created and approved before planning a day in order for that item to be considered for planning. The team productivity dropped for 30-40% in first two weeks to get settled with new process inception and spending time in creating a document while as the time passed, the team who was not confident in doing 35 story points, hitting close to 60+ story points. All that happens in less than 4 sprints. Worth it!! Isn’t it?
This approach is phenomenal when the team is co-located while teams which are not, it can be slightly modified. For instance, the team at location x can pre-groom few stories and location y does the same with another set of stories.
There is another interesting thing which I have seen in offshore and onshore are sharing the same stories. The challenge is what I work (assuming I am at offshore), I need to hand off to onshore and vice versa. For 6 day worth of story, I and my counterpart need to understand what other person has done. The wastage of time in handoff and further understanding work done by counterpart every day by both ends adds extra hours.
I have seen instances when a story which can be done in 6 days took more than 6 days because of the addition of another person. Sounds funny? Yes, it is. Even if in extremely positive scenarios, it would add 50% extra time. A lot of people think we can avoid dependency and everyone should know everything, while it is funnier that the horizon of learning is limited for an individual if you look at long term. I am not saying that we shouldn’t do that but we need to be wary of taking a right decision. For instance, if there is a production issue or a complicated story which we want more than one person to learn/work or a story must have to be completed in little lesser time. With these kinds of practices, trade-off is understood. Compromising productivity to achieve temporary priority is fine in this case.
When the team is aggressive, they pick more points and to make up that quality is being compromised. Or the team may not be able to do that, which is even worse as it demotivates the team. I always tell my all teams to start with less (less than they think they can really do it). Further, as we progress, keep on taking more and more. The constant improvement is really important.
As discussed earlier, the pre-grooming or creating SRS very much fix this issue.
In order to have your sprint successful below is what I think are very critical
– Trust each other in team
– Give focused hours. Core working hours are really important
– Celebrate every victory
– Appreciate your team members
– Provide feedback openly
– Fail faster
The “I” factor usually becomes a challenge in many sprint teams. I will pick the certain specific piece and create dependency or I am more competent, and I would do my own over working with a team. The moment you see people like this in your team, get that fixed or move those out of the team. They just create a nuisance and spoil team culture. This is just a myth for an individual as it’s very easy to replace anybody in agile. The only worry, I see here is spoiling team culture.
As an individual team member of team, the success of him/her is
Constantly learning, learning faster
I have seen less competent team while better at supporting and trusting each other ended up doing much better in terms of quality, quantity and achieving business goals compared to high experienced teams with team culture lacking. Agile is all about self-organizing teams which move up in ladder by helping each other to grow. It is so beautiful that everything is visible and individuals with “I” and “We” just do not grow. If you are not able to openly give feedback to your team member because you are scared, you would end up being just mediocre. I do less because sprint success is important and does it matter if I work just 2 hours a day because I am completed all the work I planned. Sounds familiar?
Another interesting observation what I have from some of the developers is if I don’t contribute it is anyway not visible because I can show I am pairing or stuck on complicated issues or whatever. It’s is a just wonderful myth. The agile gives so much of clarity that everything is visible.
When it comes to releasing software, I would say release as many times as you can. This would force you to think a need of having lots of tests. Again one of the common challenges is, most teams focus well on the unit test while they hardly create integration test. That is bigger killer in long run. A lot of great teams are given 20% to 30% time in a sprint just to refactor code, working on extra tests which are not there or working on nonfunctional requirements. The challenge is if it’s not planned, it doesn’t happen. The human psychology must have to be addressed. If I am given a work on Monday and I am expected to do this by Friday, I would do that on Friday even if I could have done that in 2 days. In addition to that when you have a task it has to be done.
How great self-organizing team you have, it is always good to add work in sprint board.
The fear is another cause of doing less or not doing RIGHT. Many times teams are afraid that they may not be able to complete the work hence they pick less and even though work gets completed in advance, they keep picking less. The extra time remaining is good for learning new stuff and working on tech debts. 1/2 day or one-day learning is decent for two weeks of sprint while for tech debt and other stuff, planning results better outcome. When the team trusts each other, they as the team always take credit for success and accountable for failures. It sounds better. Indeed it is. Agile encourage you to fail while with every failure you should learn and avoid repeating that mistake. When you are working on existing complicated product, and while working on the story you see there is an opportunity to fix existing bug or refactor some code, I would say you should do it. Or plan to do it ASAP.
If your team or PO is discouraging you from doing that, talk as a team. Your goal is not just to fix issue what customer reported while you should be constantly striving to make your product better. The priority can be discussed and trade off can be identified while If you don’t do it, it would never happen.
Let’s talk about scope creep. The scope creep is nothing but change of scope or change in requirements
If it’s in middle of sprint, there are only two ways to manage it
– Push it to next sprint
– Remove the same amount of work to pick new work (Do it only when it’s VERY important). Agile completely discourages it but when there is a prod issue or something similar to that sort pops in, you might have to take wise decision)
If it’s outside of sprint
Agile is excellent, it depends on the SOW you have signed. Primarily, you can take something out or you can add another sprint to your total number of sprint or whatever you have agreed on.
I personally don’t allow a team to pick work which comes during the middle of the sprint. It creates lots of confusion. Until and unless it is extremely important, you should not be picking it up. The extreme urgency like prod issue comes from customer etc. Many of the things can be planned by keeping some 10 to 20% of bandwidth to manage these support issues. If there is a huge work which would spoil the sprint, the best thing to do is to start a new sprint.
Another practice which I feel goes pretty well when you have offshore and onshore model, is to have quick sync meeting in morning. Typically standup happens in the evening which is nothing but post-mortem or status meeting who is attending that in evening. It doesn’t have the benefits of stand-up at all hence meeting in morning for such team adds lots of value.
The demo and showcase are very important, and I always prefer a practice of showing it to team and PO as and when it’s available. How great the requirement elicitation is, there are always things which get missed. I have seen teams doing Agile with waterfall model and I call that as “waterfall agile”. Most of the team members work on development for first 70% of days and in the end, the focus is on QA which is ridiculous. Ideally, you should work on development, testing, and showcase. If possible push that code to prod as soon as you can and don’t wait for the whole sprint to get completed. There is an exception to this is when you have bigger products and many customers are using it. This kind of scenarios you should be looking at a number of tests you have and what kind of dependencies to be addressed.
Agile is really very simple hence it doesn’t allow you to do too much tailoring, unlike waterfall method. Every process is simple but it has to be done diligently. You don’t work as individual while you work as a team.
Agile – The agile means able to move quickly and rapidly. Precisely the ability to both create and respond to change in order to fulfill the fast paced dynamic business environment refers to agility.
Agile software development refers to a set of protocols for building software under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, early delivery, evolutionary development and continuous improvement, and it also encourages rapid and flexible response to change.
The big question is when to use Agile. The world is moving towards Agile and one of the study shows that majority of companies would be very much Agile by 2020 and if not, it would be very difficult for them to survive. Although Agile adds value to process stream in most case while there are certain situations where it may not be apt.
While moving towards agile, one should evaluate following answers to below questions
Requirement Definition – Changing or Constant
Experience and Skills of a Team – Highly skilled or Newbies
Change – Frequent changes or Less
Resources – Dedicated or floating
Timelines – Fixed or Flexible
Documentation – Less or more
Customer Involvement – Continuous or Intermittent
Physical Location of resources – Co-located or Distributed
The mission critical applications or products probably still better be on waterfall or traditional model. Probably the 8 points mentioned above should be given a thought before taking a decision of choosing the right set of processes
It’s been few years since I started following agile methodology. When I look back it’s interesting and happy journey. Was thinking about the book (User stories applied) which introduced me to Agile world. Back then, I read the book like a story book. Now I re-read the book after two years after practicing Agile. It was a fantastic read! I thought of sharing few fundamental things for being in an agile team.
Team > Individual : When you are part of an Agile team, the focus shifts from individuals to the team . This will be a big change for those who come from waterfall model. Although during the standup meetings people talk about their achievements for the day and the next actions, it’s not the individuals work alone that make sprints successful. Things like, taking up pending tasks, helping team members complete tasks, pair-programming, looking for the overall success of the business etc. are thing which make significant impact than an individual’s ability to write optimal code/test.
Where is the Design : When I came from the waterfall model, I was surprised that there is no definite design phase. But soon I realize that design is happening in iteration over a period of time. While being in a sprint, Design happens when we do sprint planning and tasking, design happens when we do the pair programming, it happens when we do TDD. This way, there is more scope for the developers to think about code and design, than a single monolithic time slot to think through design.
Agility is different from being in an agile team : Having an agile mindset is completely different from being part of an Agile team. Being part of Agile team gives us leverage to do iterative development, do the ceremonies of agile process etc. But when we have not imbibed the principles and the manifesto behind Agile, it’s not Agility.
Communication : Focus and Communication are fundamental to any successful sprint team. When there is no direct communication, thoughts & opinions are not converted to actions. Be it daily standup meetings or technical discussions/pair-programming/or during sprint planning, connected and collaborative people can only create beautiful software.
Practice, practice, practice : There is no testing phase, there is no business verification phase, nor there is any formal review process. How can we sustain quality ? how can we insure reliability ? The answer to these questions come from the software development practices like TDD, BDD, emergent design, CI etc. Agile provides a way to use these practices. Apart from the acceptance criteria for a story, Definition of Done(DOD) governs the acceptance criteria for all stories. When we have DOD covering these practices, it becomes a standard for ensuring quality. There techniques and practices in combination with Agile process can help to deliver continuous business value while ensuring good quality.
There are an indefinite list of advantages for doing iterative development over waterfall and vice-versa. Although Agile, helps to deliver software faster to clients, there can be projects where regular waterfall model might help. We need to be choosy in selecting our process for each and every project that we work on. Provide your inputs and thoughts on this topic in comments.
Pairprogramming is an agile software development technique in which two programmers work together at one workstation and share the same keyboard. One person (Driver) writes the code while the other person (Navigator) reviews it and at the same time thinks about the big picture.
How to do it right
Understand the requirement well before you start. Spend few minutes and discuss with each other.
Agree on one small goal at a time.
Support each other
If you are a driver, focus on small tasks and quickly complete it avoid bigger issues. Trust navigator to your safety gate.
If you are a navigator, constantly review the code and think of a big picture. You don’t need to dictate the code.
Celebrate victory when the task is completed or you resolve a problem.
Changing roles few times in a day helps (Driver to Navigator and vice versa)
Encourage pairing. Do not worry about slight productivity loss in beginning. This is something I have seen many teams when new teams are formed as they don’t have experience in the pairing.
Start with a trial. Do not force individuals to pair. Let them decide who wants to pair with whom. Changing pairs constantly helps.
Pairing for more than six hours a day is not advisable.
Individuals should switch driver and navigator role when they get bored.
The Large monitors and good leg room are essential along with co-location which is absolutely mandatory.
Trust and support each other. The team culture plays a critical role.
Improves software quality without impacting time to deliver.
The focus and energy involved are much higher hence chances of making mistakes reduces significantly.
The better articulation of complexities and hidden details of coding tasks reduces the human errors.
The requirement elaboration and definition of done usually be better understood.
Build trust and help individuals to be better skilled.
The partners can switch when frustrated or stuck. The work doesn’t get compromised. The change in responsibilities once again adds energy to work.
New recruits come up to speed more rapidly in a pairing environment.
From a developer standpoint, pairing is enjoyable and valuable activity. I have seen developers who resisted pairing the first time, eventually loved it and found it to be much really useful in terms of learning, more engagement, better quality and successful careers.
It’s social skill and it takes a time to do it. The best pairprogrammers exactly know when to say let’s try your idea first. Do not expect the outcome of pairprogramming from day one. It takes some time to do it in right way.
No benefits are expected if both the programmers are not actively engaging themselves. It’s “programming it loud’ methodology” hence it is essential that the driver and navigator constantly communicating. The silence kills the benefits of pairing.
If the two people have personal challenges, the pairing cannot be forced upon. The trust and mutual understanding between the two people is absolutely necessary
Experience mismatch is another bigger challenge. The senior programmers often want to have more control and give a little room to junior programmers.
View pairing as one person watching, the other person doing the actual work. That becomes boring and disengages the person watching, eliminating any real benefit from this practice.
Pairing should be avoided for very simple tasks or tasks which are very clear and can be done in little time.
Pairing needs to be done by two. The moment the third person added to it, it cannot be called pairing anymore.
The co-location is absolutely mandatory. The absence of co-location where the work is shared between two programmers is called sharing over pairing.
Force the pairs or identify them ahead of time which may not be right in many scenarios. The best approach is to let the pairs form and swap by their own.
The pairprogramming is mentoring while it should never be. Programmers often pair with somebody with the goal to learn technology and domain. That is called either as mentoring or knowledge transfer. This should be treated as knowledge transition and expecting less than one person productivity is a fair expectation.
Two people working on the same story but different tasks individually is considered pairing while IT IS NOT! It is sharing the work but not pairing.
I have often seen individuals complete half the task and hand that over to another team member in evening sitting in a different country and assume that it’s pairing. This is again sharing of work and comes with extra cost due to unknowns, handoff and understanding each other’s work.
Doing agile requires pairprogramming. The reality is Agile manifesto never talks about pairprogramming.
The initial resistance of programmers that pairing is not a right thing to do. Most programmers like it when they try it. Others don’t do it right and start believing it’s a waste.
The pairing would reduce the productivity to half. This is one of the most debated topics. I have personally experienced that when it is done in right way, it improves the overall productivity of more than two people working individually.
The agile roadmap is often confused with product roadmap or scrum ceremonies. The agile roadmap is indeed much beyond that. If it is not just the scrum activities then the question arises in terms of what is agile roadmap all about? How important is it to know what happens before sprint planning? For most of us, sprint planning is the beginning of agile project while it is not (Practically it can be considered as mid-stage). A lot happen before ‘sprint’ ceremonies. The agile roadmap would probably answer the entire process that is being followed to accomplish the project.
At a very abstract level, the agile roadmap has 7 phases listed as below:-
Product Owners in conjunction with senior leadership identifies the product vision.
The product vision talks about – What your product is, and what it entails? How it would support your company or organization strategy and who is going to consume it.
There are many more factors being considered here including the market, complexity, feasibility etc.
This phase defines high level of product requirements which are written at high level (EPICs)
The discussion between product owner and other stakeholders enable PO to define
High level estimates (Probably ROM -> +/- 100%).
The EPICs are further broken down into individual stories.
An agile project will have multiple releases with the highest priority features being picked up in order.
During this phase release timing for the specific product is determined.
The release plan must have to be created at the beginning of the project.
The number of sprints, team staffing and capacity is being looked at as well.
The sprint team works with PO to groom the requirements based on priority.
Technical and product dependencies are discussed.
Individual tasks are created for each requirement. The next level of estimates are created (+/- 20%). Planning poker, relative estimate, and WBD are quite commonly used to provide an estimation. Based on the maturity or project and organization in the specific area, complexity based estimation can be utilized as well.
The team gives commitment by looking at the capacity and next level of estimates.
This happens at the end of the sprint. All the stakeholders sit together and discuss
Things which worked well
Areas for Improvement or things which we should stop doing it
This meeting should also look at the action items of the previous retrospective and see where we stand. If the previous action items are not addressed, those should be included in current retrospective.
Many times the first three phases are ignored by agile teams. The ultimate success requires or expects that the entire agile team to be well versed with first 3 phases as well. They should be part of it from day one.