Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Should the product owner take part in estimating user stories?
Furthermore, in our team not all developer familiar with every part of the system. Client and server side is a usual separation. GUI guys are not too familiar the server side code and vice versa. Should the GUI guys estimate server side stories?
I know that specialization is more or less against Scrum but we've just started using it.
The entire team needs to be present during Sprint Planning. This includes the Product Owner. However, only the Development Team actually estimates the user stories.
Sprint Planning is where the bulk of Scrum estimation is performed. While the Product Owner doesn't actually participate in the estimation itself (e.g. he doesn't get to vote during Planning Poker), he is part of the estimation process so that he can answer questions about the stories being estimated, help the team refactor stories, or adjust the Product Backlog priorities in real-time during the planning session.
The entire development team needs to participate in the estimation process, even on stories where they will be playing a secondary role. The reason is two-fold:
Everyone has a role to play in a well-written story.
A client-side story still needs data from the server side, and vice-versa. A programming story needs testing, documentation, and deployment. A story that doesn't involve most of the team is often a project smell that you have the wrong team in place, don't have a cross-functional team, or have a flawed user story.
A consensus estimate is usually more accurate.
By ensuring the whole team is involved in the estimate, everyone's skills can be brought to bear. Will your server-side programmers always know what their API changes will do to the client-side? How much technical writing will be involved in this new feature? Are there any required changes to the testing infrastructure that the QA guys need to implement to test this new feature?
Making sure that the whole team agrees to an estimate means that all eyes have been put on the task, and that the entire spectrum of team skills are in play. Tasks can still be mis-estimated, but you should find that you have fewer unforseen problems that could have been avoided by having the right people look at it during Spring Planning.
Remember, part of Sprint Planning is to decompose stories into tasks for the Sprint Backlog, and add additional tasks to ensure that the user stories meet the "definition of done." You are more likely to get this right when all the players are involved.
The holistic approach to estimating and delivering features is the cornerstone of agile techniques. Whole-team estimation keeps the project planning process transparent and visible to everyone, increases intra-team communication and buy-in, and is essential to the Scrum process. If you aren't taking a holistic approach, I'd argue that the essence of the methodology has been lost.
If you have just started using Scrum then it will take some time for the team to adjust. In the meanwhile, make sure that you improve upon two things:
Good user stories are written so that each one has a vertical thin slice of the system that you are building. A vertical slice would include some work from the following components (if applicable): client side, server side, architecture, database, web service, testing, etc. This will reduce the problem of estimating server-side code by client-side team members and vice versa.
Relative sizing of stories require that all users stories are assigned story points based on the effort required to complete each story as compared to the other stories in the backlog. Required effort would include the story size, complexity, doubt factor. This will minimize the problem of knowing how much time will be required to complete a server-side component vs. client side because the whole time can equally judge if Story A requires more effort compared to Story B.
Now to your first question, product owner should participate in the estimation exercise to explain the stories and answer any questions from the team but the PO should not estimate the stories because he/she is not responsible to complete and deliver the story (the team is responsible).
