Estimations in scrum/agile environments often gets tangled in conversations about how big of an effort that is required. The questions that are often asked are “how much of effort?”, “how long/sprints it will take?”, “Is it too complex?”
Scrum provides a model where these questions are easily compressed to a simple thing called story points. Story points is a number denoting the complexity/effort/time taken by the team to solve a problem (story). Story points are often a number of Fibonacci series. (1, 2, 3, 5, 8, 13 …). The scrum team defines what it means by a 1 pointer story. For example one of our teams defined a 1 pointer as “one line of code change”. Also as the number of unknowns in a story is high, team provide higher story points for the story.
However the size of the story points is not important because
- Story point size is specific to the team and can not be used to compare teams. A story could be sized differently by different teams based on the understanding of the product, technology and experience.
- When a management provides a commitment on a given epic/release to the customer, the delivery timeline is often determined by the velocity and not by individual story sizes.
- Story points are a relative sizing of the stories and not a exact reflection of complexity/effort
- Bigger story points does not mean higher customer value. A refactoring story or a story of lower business impact could be sized bigger.
- Story points are time bound. The team could size the story differently depending on their understanding, as their knowledge/understanding changes their story sizes also change. This is one of the reasons some teams re-look at the story sizes during sprint planning although they are sized.
Please let us know your thoughts, using story points? does size matter?
The Scrum roles are
Product Owner – PO is a key stakeholder in an Agile project. He/She is responsible for defining or detailing the vision, understanding organization goals and ensure to align project goals with it.
- Defines the features and stories of the product. Elaborating requirements, clarify doubts and clearly stating acceptance criteria.
- Review every functionality and accept or reject the work accomplished by the team.
- Responsible for release planning and further prioritize the work.
- Owns product backlog, release backlog.
- Remove functional impediments and constantly answer product related questions to the team.
- Constantly talking to other POs to align product/project changes with business unit/organization goals.
- Responsible for the return of investments.
- This is management function of Scrum.
- Facilitate the daily standups.
- Setting up retrospectives, pre-grooming, showcase and other meetings.
- Remove impediments or obstacles for all kinds (technical, functional, resource etc.)
- Co-ordinate with POs, Team, Manager and all the project holders.
- Ensure team productivity and closely working with them to ensure quality requirements are enforced.
- Ensure team understands the processes and adhere to them.
- Protect team from external interferences and interruptions.
- Responsible for actual implementation.
- The recommended size is between 6 to 10 people. The best practice is to have 7 member team.
- All the members are expected to be full-time. The exceptions could be DBA or some specialized skill needed on a temporary basis.
- Proactively identify ways and opportunities to improve the performance of the team and constantly get better.
- Are set of programmers, DBAs, tech writers, technical experts, domain experts, independent testers etc.
- Must be self-organizing.
- Constantly communicate with the team and ensure to meet sprint goals.
- To share all information in daily standups including “work in progress”
- To support each other. Most importantly consider sprint goal a priority over individual goals.
- Avoid accepting outside or extra work without consent from team.in