WARNING: The following post talks about “commitments” and “planning” if your agile worldview finds these terms dangerous and unsafe, continue at your own risk. What is Commitment Driven Planning? Commitment Driven Planning (sometimes called Capacity Driven Planning) is a technique that lets a team determine how much work to bring into the sprint based on how much time they have to do said work. What do I need for Commitment Driven Planning?
Setup For this retrospective you’ll need sharpies, post-it notes and a wall, window or whiteboard on which they can be stuck. Setting Expectations At the heart of this retrospective exercise is defining expectations for yourself and your teammates. Start by explaining that on most teams, there are varying expectations. Some people expect different things from different people and from different roles. The exercise as described below is focused on a Scrum team, but the questions could be adapted for any team.
Working software is the primary measure of progress. – Principles behind the Agile Manifesto Pixel perfect design mockups, UML diagrams, detailed user stories, automated tests, thousands of lines of code and hours of discussions. These are just a few examples of the endless amount of stuff we can spend time creating, tweaking, editing, testing and reviewing. However, nothing shows progress quite like working software. So what is working software?
Physical Boards Please I recently started working with a team who had been introduced to scrum as part of their organization’s adoption of agile. Their only experience with scrum was through the lens of a popular agile project management tool that rhymes with alley, as in “After using this software I want to vomit in an alley”. When they had the chance to use a physical board, they jumped on it.
Here are the slides for my presentation at the May 2012 Phoenix Scrum User’s Group meeting. If you attended the meeting and have any further questions, please contact me, email@example.com. Retrospectives: Best Practices, Common Problems and New Ideas Retrospectives: Best Practices, Common Problems and New Ideas from Clayton Lengel-Zigich View more presentations from Clayton Lengel-Zigich.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. – Agile Principles Manager, Tear Down These Walls If you were tasked with designing a system that made spontaneous collaboration difficult, you couldn’t go wrong with the modern cube farm. Members of a “team” dispersed over an area of the office, isolated in their drab tchotchke ridden cubicles. Instant message, e-mail and chat might be great for passive communication, but when it comes to real collaboration, being physically present is essential.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. – Agile Principles Self-Organizing Allow the people doing the work to self-organize and discover the best implementation they can given what they know right now. Protect them from organizational politics and outside distractions, enable them to focus on the work at hand. Self-Directing While we encourage self-organization, we remember the need for direction.
Business people and developers must work together daily throughout the project. – Agile Principles Email is not Enough Working together involves more than exchanging e-mails about the software. It’s more than passive instant messenger conversations. It’s not reviewing a digital agile tool in isolation. Working together means collaborating, negotiating and exploring the software that is being built. Too Busy for Success? If you’re too busy to interact, fairly frequently, on a daily basis with the rest of the team, you’re too busy to enable product success.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. – Agile Principles Quick Feedback A short feedback cycle is incredibly valuable. A short feedback cycle helps ensure you’re building the correct thing. A short feedback cycle helps you decide if you should keep going. A short feedback cycle helps you know if you should stop. Product vs. Project Shift your mindset from working on a project to working on a product.
When working with user stories, story points and SCRUM, it is not uncommon to come to the end of a sprint and realize that a smaller story took longer to complete than a larger story. While this is an excellent reminder that story points reflect complexity, not effort, it is often misinterpreted as an indication that remaining stories need to be re-estimated. Basic probability distribution shows us that over a large enough sample, all three point stories in the product backlog will take about the same time to complete.