Posts

Showing posts with the label Sprint review

3 ways of project planning and which one you would prefer!

Whenever we set a goal, we or people who are concerned always ask when this goal going to be achieved. Basically, we start by setting a goal which is expected to deliver some value. How do we determine if this goal will actually result value.What is the measurement criteria of a goal. Consider an example, lets say your goal is to learn Python Programming language so that you can build professional websites and work for companies part time to provide solution in Python. How will you measure value. First of all this is a individual goal which means no one is affected by this goal, however if this goal is set by the employer then concerned people will be your manager who would like to consider you in the python projects. So how will you determine the size of this goal and duration it will take to achieve. And the way to achieve the determine is through planning ! There are 3 ways you may go ahead planning for this goal: Over- Planning   - In this case you will just identify e...

Poka-Yoke - Continuous Improvement Technique

Poka-Yoke   is a device or method that prevents people from making mistakes. The word in Japanese means mistake proofing or error proofing. What habits we can have in Scrum Sprints: 1. PO must have this constant habit of thinking "Is this User story solving the problem"? 2. Developers must do code check-in when all the team members are there. This will create a stable build. 3. Scrum Master need to constantly think of not only current sprint status but also about next sprint risks/dependencies. 4. QA must have a habit of checking the software on every code check-in and not when all the features are available. If any logical feature/test case is finished QA should start verifying it. 5. QA must interact with Dev on regular basis to share the observations. Bugs reported much early in the sprint cycle is better than later. Can someone think of any other habits?

Sprint review meeting consideration

PO and team to demonstrate the working software increment to other stakeholders. The goal is to solicit feedback and then make changes to the backlog if appropriate. Think of it as User Acceptance Testing. Talk about the release plan and how the current sprint affected it. The PO should also be highlighting what is comming up in the next sprint. How are we going to deliver the potential business benefits of Agile? Did we pick the right delivery approach for the product and the right stakeholders? Did we coach and engage them well enough? Do they understand the importance of incremental, iterative development and the frequent feedback loops? If business is not available or interested are we really working on the right thing in the right setting? Are we engaging business in the right way?