We are currently working on a project where we receive a lot of change requests, and the client insists that we should deliver the changes in the current sprint!
Can I add the new work to the sprint backlog as a new task? Sometimes the tasks' effort changes, like earlier it was an 18 hour job but is now a 32 hour job.
How can I accommodate these changes without making a weird burndown chart? Is it okay to add tasks to a sprint in progress?
Can I add that to the sprint backlog as a new task ?
Yes, you can add stories to a running sprint, if the team agrees to it. It's not a good practice though as it reduces the usefulness and predictive ability of the methodology.
Some times the task's effort changes like earlier it was an 18 hr job now it's a 32 hr job
This is relatively unimportant: that's why stories are not measured in hours, but in points: the time estimates may vary during the sprint. That said, you only need to keep track of the time left, not the time elapsed.
If you feel that stories were estimated as simple and get more complex as the sprint is developed, there might be a few underlying issues:
Did you have enough information during the planning meeting to estimate the story correctly? In other words, has the scope stayed constant but the complexity of the task turned out to be higher than predicted?
Did you estimate the original story correctly, but the customer changed their mind during the sprint? If they did so because they legitimately changed their mind, then you should abandon the story and start a new one. If they are, instead, adding scope, then you should add new stories to the backlog for that.
How can i accommodate these changes without making a weird burn down chart ?? Is it okay to add tasks to sprint in progress ??
Yes, burn down charts can go sometimes up instead of down. It's probably not something you want, though!
All in all - these are the basic rules which you should look up to:
Only the team can accept new stories in a sprint. They cannot be forced on them. Doing so is simply contrary to basic agile principles.
New scope should always be a new story.
A new story can be added to a sprint if you take a correspondingly sized story out (the new story needs to be estimated by the team, and the team must accept this change as feasible).
A significantly changed sprint can be abandoned. You may stop the sprint, and start a new one from scratch, with a new planning meeting. Obviously, try to avoid this if you can.
As new information emerges the team might discover that it will take longer (or shorter!) to develop a story. This is expected. Story points don't change, hours left change.
As new information emerges the product owner might discover that they need more stories (or less!) than originally thought. This is expected. Add or remove stories from the backlog with impunity. Add or remove stories from the sprint only if the team agrees to the change and commits to it.
We are currently working on a project were we receive a lot of change requests, and the client insists that we should deliver the changes in the current sprint itself!
This is a sign that You Are Doing Scrum Wrong™. While there are certainly edge cases where stories can be added or removed from the Sprint, or when the Sprint Backlog gains or loses tasks necessary to complete the current Sprint Goal, that isn't really the issue here. Instead, the issue appears to be that the client is not working through the Product Owner to review progress and adjust scope at the framework-defined inflection points:
Stakeholders should not be allowed to change scope within the current sprint without the active cooperation of the Product Owner and an explicit Early Termination of the current sprint. Violating this principle will create invisible work and untracked overhead for the project, which is a big no-no.
That isn't to say that the development team can't work with the stakeholders or an end-user defined in a user story to clarify an in-sprint story or gain insight into the optimal implementation of a feature, but such interactions should not change scope or compromise the Sprint Goal defined during Sprint Planning.
The Product Owner and Scrum Master must work together with the stakeholders to enforce the integrity of the sprint, and to educate them about when (and how) to make changes to the project's scope within the Scrum framework.
The Ideal
All requirements are completely predictable. By doing enough analysis up-front, extra work will be discovered before the sprint starts. Accurate estimation will therefore be possible, and this question will never arise.
The Reality
Parts of your project will be new things you've never done before (otherwise it would be exactly the same project that you did before, and that never happens). Discoveries are inevitable, both in analysis and development. You can't estimate things that you've never done before, and trying to do so will usually result in floundering and / or estimate padding.
What to do about it
Recognize that there's always uncertainty in development and be adults about it. The end of the sprint is there for you to focus on getting feedback from your stakeholders, and that feedback is far more important than any story-point estimation.
Arguments over these discoveries often result in people spending more time trying to analyze the newest, most risky elements of a project ahead of time. Analysis isn't as good at flushing out those discoveries as actually delivering something is (or Waterfall methodologies would work), so when those discoveries are made, it's very important to focus on delivery and feedback.
Otherwise, analysis paralysis sets in, and those elements end up getting pushed to the end of the project instead, when there's no time to react to them.
The purpose of estimation and velocity measurement is threefold:
Pure Scrum doesn't mandate story points and velocity measurements. Instead of making promises around points, consider making promises around aspects of stakeholder needs on which you'll deliver or showcase something for the purposes of learning and feedback. By addressing the riskiest aspects of a project early on, you'll learn fast, de-risk the project (and help to make more accurate plans), and gain stakeholders' trust through addressing the things that stop them sleeping at night.
Under no circumstances should the story points ever be used to "punish" the team. That will only create a rift between the PO and other team members, and the PO ought to be part of that same team.
If you're looking for a tracking mechanism, and the scope changes happen regularly, consider a burn-up chart, or CFD, instead. That will let you track your work against the scope over the longer term, and you'll also be able to see how scope itself is changing.
There's quite a few options for handling unplanned work during a sprint. As an agile practitioner, you have a number of approaches. Ideally the development team determines what can and can't be done during a sprint. But if an issue raised by the PO is required to be inserted into the sprint then you can :
1/ Absorb it.
2/ Break up affected stories and rollover into following sprints
3/ Replace item to match velocity.
4/ Make an "ad-hoc issue buffer" item. Allows for rogue PO's or complex issues that can't be fully groomed until work has started.
5/ Improve Prioritsation (ie, Say "No").
6/ Identify and remove dependancies (ie remove blockers from sprint until source cause resolved)
7/ Adapt process to Kanban.
(source: https://medium.com/agilelab/strategies-for-handling-unplanned-work-during-sprint-2f89697509ff)
I definitely think that you need to address the issue of "change requests from the client," perhaps at a contractual level. Change is the mortal enemy of software development, especially when those changes are flying in while the affected piece is being written. The client needs to be made to understand that such an un-disciplined approach is going to wind up costing him money, and threatening the stability of the product upon which he intends to rely.
In my earliest consulting days, I read a book on consulting contracts by the late Herman Holtz (nee "Hermann Holz"), in which he described an umbrella contract and task orders. The work was to be carried out by creating task orders, obtaining client approval for each one, attaching a cost to it, and then carrying out the order. I used this system for over thirty years with great success.
(The gentleman wrote a number of excellent books. I recommend them.)
The key "win" is that it formalizes the change-request process in the eyes of the client, and ties it to "spending money." The process of defining that order, to the point where the client has to put his John Hancock to it, is in and of itself extremely valuable. It also greatly reduces the chance of misunderstanding. I always politely made it clear: "Your signature is a binding authorization to carry out the work as described. If you change your mind, that's another task order."
I got most of my work by means of referrals, and several prospective clients said that they were attracted to my consultancy because we used a task-order system. I know that it was key to our long-term profitability.
Building contractors, and other makers of tangible things, use these practices routinely. They apply equally well to the building of intangible things such as computer software, which are far more complicated.
