20

TL; DR Agile release planning is based on fixed-length, normed-capacity cycles that operate on dynamically-planned and dynamically-scoped features. In Scrum, fixed-date release planning must be handled by controlling scope to meet the deadlines, as you cannot have both fixed-date and fixed-scope deadlines simultaneously. This is rarely a practical problem, ...


12

Not surprisingly, I hear that question a lot. The basic problem with the question is that Agile disagrees with the fundamental idea of a fixed-scope/fixed-timeline project. In the question you were asked, there is the assumption that the end date of a set scope is knowable and the problem is that we are bad at knowing it (estimating). That's not really true. ...


9

You have historical data about your team The only tool you have in Scrum to help this situation is your velocity. I believe you know your velocity - how many story points you do in a sprint -, check the product backlog and do planning on each user story. Using these two, you'll have an estimation on a possible delivery date. delivery in weeks = ((number of ...


6

As soon as you said "The team provided guesstimated hours" I recognized an issue here. When you do high level release management, you have to realize that it even applying story points to epics is a really inaccurate tasks and can only be used in broad strokes. Trying to actually estimate hours is bound for failure. As some others have said, yes, it sounds ...


6

Go for it but: Don't story point estimate your epics and assume that those story points will later be equal to story points on actual stories of the corresponding stories belonging to each epic. Or t-shirt size your epics instead and putting a priority on them like high, medium, low. An XXL, high priority epic is probably the first epic you actually want ...


6

Typical approach Scrum by-the-book assumes that you release at the end of iteration, then you demo the product to a client. "Release" and "demo" of course may mean different things depending on a product you build, e.g. back office app for big corporation versus an app directly addressed to end-users. Most Scrum teams try to release at the end of timebox ...


5

Zsolt has some good starters, I'm giving him a vote up. Scrum works very well for fixed release dates so long as you recognized a simple reality. That being with Scrum you can have one of two truths. 1- You either get all the work in the backlog done. You just don't know when. 2- You release on a specific date with the work you've managed to complete by ...


5

I second ctrl-atl-delor (+1!) - you should invest on automation. Agile methodology helps on how work is organized, but regardless of the methodology, you should automate as much as possible of your work. We have a similar scenario in our project - and I'd guess it's fairly common on legacy applications. You have two main fronts of work: SDLC automation:...


4

Scrum originally didn't have anything related to releases, but fortunately it has been changed and there is a thing called Release Planning. During this meeting the Scrum Team and the Product Owner sit together and see when the product can be released. It is a high level planning meeting. In reality, the releases are set by the projects and the stakeholders....


4

This is responsobility of Product Owner and Development Team. Product Owner: In article Roles in Disciplined Agile Delivery is written following: Product Owner. In a system with hundreds or thousands of requirements it is often difficult to get answers to questions regarding the requirements. The product owner is the one individual on the team who ...


4

Sticky Note planning will be with us as long as people get up during a meeting and start to draw on white boards without thinking. As long as people wave their hands in meetings. As long as they walk up to the projector screen and point at the slides. This goes to the same reason hand written notes are the number one recommendation for note taking. Our ...


4

Sergey, the steps you describe will make your release planning more precise, but not improve the accuracy. Don't fall into the trap of thinking that having a detailed, explicit process during release planning will improve accuracy. It's a trap that we are biased to fall into because, as humans, we seek to create a sense of control where there is none. The ...


4

Well done you are doing a grate job. Scrum has lead you to diagnose several problems with your process. I would recommend devops, developers and ops merge. They then fully deploy to testing (that is the same as operational). After testing you press a button to deploy to operational. Docker is a good tool to help with this. The other thing (and most ...


3

It sounds like your interviewers were defining a "release plan" as a fixed scope and fixed date scenario. One simple way to improve the accuracy of those plans by at least 30%. Simple Answer Slash quality standards as needed to meet the deadline Seriously though, this sounds like a trick question for a shop running Scrum. Fixed date and scope projects are ...


3

Ask your team what works for them If your entire team is in one location, physical wall boards with sticky notes foster team spirit and collaboration. "Our board is more than a tracking device – we stand next to it and have conversations, like the office water cooler. We write on cards and wave them around and move them. It’s a wonderful communication ...


3

This could be due to a number of things: The requirements. The less detailed and clear your requirements are the more you can expect there to be significant error in your estimates. Garbage in yields garbage out The estimating process. If your requirements are good enough to provide reasonable estimates the estimates can still be off if the process isn't ...


3

TL;DR Release planning is an estimated management target, generally based on level-of-effort estimates of large themes or epics. Sprint Planning is a team commitment based on iteration-sized user stories. They serve different functions, but the key is to remember that estimates are not guarantees. Schedule changes do not necessarily imply that your ...


2

In Scrum, we teach teams not to take on "Risk" where it is not theirs to take. Your team did their best estimate at the start and as time progresses, you and the client realise that the team's ability to estimate is very bad. The first question I am going to ask the PO, is what risk mitigation did he/she have should a team likely estimate incorrectly? I ...


2

From what you write you estimate features because you need predictability, namely you want to know how many and which features you can pack into the next release. At the same time you understand that requirements are changing over time which means that your estimates are going to change as well. You try to cope with it estimating and re-estimating in details ...


2

The idea of Scrum is for a team to focus on delivering what a customer wants. To do this we do some work, demonstrate it, listen to feedback and then adapt. This approach recognises that it is hard for a customer to get their requirements spot on up front. It is much easier to build a successful product when you have constant feedback and adaptation. If a ...


2

It sounds like you are in a low trust environment. If you are in a low trust environment you need to do as much planning as required to get started. Once you start, and deliver, you will begin to create trust and erode the need for such detailed planning up front. Your answer is the only viable one. This is so typical of large organisations at the ...


2

Making release planning more accurate means considering following cautions: But, you can not avoid considering 15-20% cushion. Understand resources and their efficiency levels [This is possible only if you are working with team for long time] Keeping a tab on iterations and Quality control.[This is possible if stake holder communication and discipline is ...


2

I will avoid going into the comparison with a fixed date release plan and just throw some suggestions how to improve the estimates of the user stories and related tasks (once you know how much they take and the team velocity is pretty straightforward to see which scope can be achieved in a given release). Split the bigger stories; smaller stories/tasks are ...


2

There's few trivial story's/bugs left but they took extraordinary effort to finish. Team seem's not to be exhausted. But this is always endangers and shifts delivery date. and team understands that there is a problem. But thinks it's a natural order of things and don't knows the root cause and prefers to leave things as is. Is your team by any chance ...


2

Terminology Housekeeping Velocity should be understood as a measurement of "Done" software increment the Development Team produces. This is because it is worlds more important to measure this than "velocity" of task, workflow step, etc. Now that we're talking "Done" i.e. Definition of "Done" in Scrum, let's talk about how to reduce the risk of stuff not ...


2

You're using the term velocity in an odd way. The velocity is the amount of effort that a team can put into developing stories per sprint. It's usually measured in story points. The average of the velocity serves for release planning or to guide during Sprint Planning how much work can be done in one sprint. It sounds more like you're talking about some ...


2

When I am reading "near to the end of a sprint" it means that your sprints are too long. You need to shorten your sprints. That's the main thing that you need to focus on. You have the answer within your question.


2

It is the task of the dev team. not estimated separatelly since its a task, its taken into consideration when estimating the story Team can create a separate task in the backlog, if the team feels that it helps them. 4. Story isnt done


2

The CSM Certification is a good start for just about anyone involved in Scrum/Agile -- its goal is to give everyone a solid foundation in the principles of the framework. I think that would probably get you the most ROI. That said, I'll give the caveat here that I always give with recommending Scrum certifications: the cert itself is fairly valueless. The ...


2

Scrum.org focuses more on delivery of software and the material reflects this. In the interests of fairness I should point out that I am a licenced PST, and that the Scrum Alliance also have similar courses in name. For the theory I would recommend the Scaled Professional Scrum (SPS) as it focuses not only on release, but release at scale. It covers many of ...


Only top voted, non community-wiki answers of a minimum length are eligible