Monday, 27 October 2014

Why the Product Owner is important in Scrum?


Scrum product owner

Responsibilities of a Product Owner include determining the project's initial overall requirements and kicking off project activities; this may involve interaction with the Program Product Owner and the Portfolio Product Owner to ensure that the project aligns with direction provided by senior management. He represents user(s) of the product or service with a thorough understanding of the user community. He secures the initial and on-going financial resources for the project, focusing on value creation and overall Return on Investment (ROI) and assesses the viability and ensures the delivery of the product or service.
Product Owner must understand the needs and priorities of the stakeholders, including customers and users, and hence this role is commonly referred to as the Voice of the Customer.
The Product Owner represents the interests of the stakeholder community to the Scrum Team. He/she ensures clear communication of product or service functionality requirements to the Scrum Team, maintains a dual view, understands and supports the needs and interests of all stakeholders, while also understanding the needs and workings of the Scrum Team
.

Scrum product owner responsibility

He also defines the Project Vision and helps get funding for the Project, helps finalize Scrum Master for the project and identifies Stakeholder(s), helps develop a Collaboration Plan and Team Building Plan with Scrum Master(s), creates Epic(s) and Personas, prioritizes Prioritized Product Backlog Items, defines Done Criteria, creates Release Planning Schedule, helps determine Length of Sprint, helps create User Stories, defines Acceptance Criteria for every User Story, approves User Stories, facilitates Scrum Team and commit User Stories, explains User Stories to the Scrum Team while creating the Task List.
He also provides guidance and clarification to the Scrum Team in estimating effort for tasks, accepts/Rejects Deliverables, provides necessary feedback to Scrum Master and Scrum Teams, updates Release Plan and Prioritized Product Backlog, helps deploy Product Releases and coordinates this with the customer, participates in Retrospective Sprint Meetings.
There are many challenges faced by a Product Owner. Transforming customer’s ideas into tangible product deliverables: Prioritizing features is not always easy and may involve trade-off decision making. Convincing/achieving consensus among all stakeholders for every decision is tricky. Product Owner needs to be in control and trusted by the stakeholders to effectively play his role. 
Be available when additional inputs are required by the team: The Product Owner needs to achieve consensus among various stakeholders and keep them in the loop. Product Owner may be involved in business value related activities that may keep him occupied. The Product Owner may not be always available at the team location.

Scrum product owner plan release

Plan release and sprints to deliver maximum value at the earliest: The balancing act that the Product Owner plays between the Scrum Team and the Customer is a delicate one. The Scrum team may prefer a Release Planning Schedule and Sprint lengths which may differ from what the customer wants. It’s the Product Owner’s job to ensure that the maximum value is delivered as early as possible ensuring better ROI to the customer.

Fore more detail on Scrum visit the following link:-
http://agileprojectblogs.wordpress.com
http://agile-projectblogs.blogspot.com

Sunday, 26 October 2014

Changes to Sprint in Progress


Scrum is a simple framework which believes in responding quickly to changes in business environment and the ability to respond to changes is one of the reasons that made Scrum popular. The Product Owner is responsible for getting the Product Backlog ready and prioritizing the items in the Product Backlog. The Scrum Master and the development team will use the Product Backlog as the basis for planning the Sprints based on the priority of the items listed.
We could come across situations where the product owner has to decide to add/remove any item from the Product Backlog or change the priority of the items listed in the Product Backlog in the middle of a Sprint. This could be a challenge for the Scrum Master and the Development Team as it would hamper the Sprint in progress, especially changing the priority of the backlog items. Even though Scrum has enough room for responding to change, the mid-sprint alterations should be kept minimal and should not be tolerated unless very badly required. The sprint backlog user stories must not be altered in the middle of a sprint except in the rare scenario something far-reaching emerges that can’t wait until the next sprint.


There are several negative implications on the Scrum team when a mid-sprint change is required. Mostly in such cases, the current Sprint will have to be stopped and a new Sprint will have to be initiated right from the Sprint planning stage. This would affect the morale of the Scrum team and the team will lose its momentum. Also, there will be a great deal of time loss and delay in product delivery. Having said that, if the task is something of top priority and cannot wait till the next sprint, then the team should have the flexibility to include it in the current Sprint if possible or kill the current sprint and start a new sprint. In such cases it’s up to the Scrum Master on how he handles the situation. It has to be noted that adding a new task to the current sprint could cause difficulty in managing the Burn-Down chart.


The Product Owner has an important role in minimizing/avoiding mid-sprint changes to Product Backlog. The PO should have clear visibility and thorough idea about the needs of the customer and the end product he wants. This would help the PO in preparing the Product Backlog meticulously; prioritizing the back-log items accurately and minimize drastic pop-up of business requirements at a later stage.



Sunday, 19 October 2014

WHAT IS AGILE

What is scrum/agile 


Agile methodology is a dynamic project management approach to software development and implementation. Within a few years of its inception, Agile methodology has become popular because it is both developer and customer friendly. This is because—unlike the traditional Waterfall approach.
For more info watch the following video on scrum


Agile methodology 

Agile methodology is an adaptive approach that permits changes and modifications to be incorporated into the overall project plan at multiple points.
The hallmark of Agile methodology is the incremental and iterative approach to software development. In other words, the entire project is broken down into various customer-valued features that are developed in small repetitive cycles so that these features are delivery ready at the end of each iteration. The frequent delivery of business-valued features is customer as well as developer friendly. This is because, first, the technical team and stakeholders work collaboratively; second, this saves time and money; third, constant feedback from stakeholders enables developers to continuously evolve the software; and last, this promotes lightweight framework with more emphasis on working software than on documentation.



Agile methodology Key Practices

One of the key practices is daily meetings in which the team members inform the entire team on the progress of the project and discuss issues faced and obstacles. This helps the team foresee potential risks and work toward resolving them. Thus, close communication among the team members, increased productivity, evolutionary approach and reduced risks are the four pillars of the Agile methodology. Agile can be best described in the following four basic principles enshrined in the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation

Responding to change over following a plan


Other Must Read posts

                                                  1.what-is-empirical-process-control/
                                                  2.sbok-scrum body of knowldage