| Artifacts | Meetings | Roles | Blog |
INVEST
This blog provides insight into Scrum
Independent – The Product Backlog Item (PBI) should be self-contained, in a way that there is no inherent dependency on another PBI.
Negotiable – PBIs are not explicit contracts and should leave space for discussion.
Valuable – A PBI must deliver value to the stakeholders.
Estimable – You must always be able to estimate the size of a PBI.
Sized – PBIs should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
Testable – The PBI or its related description must provide the necessary information to make test development possible.
Epic, Features, and Stories
Epic – a large user story, effectively a description of a product feature that cannot be delivered as defined within an iteration and is therefore too large to be estimated. Epics are for stakeholders, users, and customers. User stories are for the team.
Features – a distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders. A feature is something your product has or is… this is typically functionality offered by a software program that enables users to do something
Stories – a description of a product feature used for planning and scoping purposes. User stories will be decomposed to a level that can be delivered in a single iteration and provide value. User stories identify what someone wants to accomplish with your product and why.
Self-Organizing Teams
Utilizing self-organizing teams in agile development can be greatly beneficial for the following reasons:
Speed. Self-organized teams decide how to meet deadlines in a way that works for everyone and can turn around a product much faster.
Agility. Priorities can change. Self-organized teams can quickly shift gears. Values that suddenly take higher priority can be moved up in the queue without interrupting people in the middle of other tasks or leaving questions about what must be done and when.
IQuality/customer focus. Self-organized teams are built to focus on what the customer wants or needs, and uses such feedback to improve the product and process. Instead of just “doing what the manager says,” the team is working to make the end goal better for the sake of the buyer/user.
Less time on team management. Assigning work, checking statuses, verifying that everything is done — all this management takes time. A self-organized team tracks and reports its own progress.
A true team. Many teams have a “main person” or the “go-to guy.” What if that guy quits tomorrow? Self-organized teams understand each other’s roles and tasks far more and rely less on one particular person as “owner” of something. That means it’s easier to handle losing employees, and it takes less time to train new ones. (However, it is a misconception that Agile teams can handle frequent turnover without problems.)
Employee satisfaction. Employees each have a purpose and know what it is. Instead of blindly following orders, team members are invested, choosing how best to accomplish a goal and then moving the project forward together.
External Links for more information on Scrum Framework
https://www.scrum.org/resources/scrum-framework-
Catalyte Scrum Blog 