How to divide and conquer User Stories

The other day I had a conversation with a colleague on Such little snippets about writing stories. At one point we came to talk about to split user stories. I'm a big proponent of user stories max is 1-2 team business days. My experience is that this gives the stories that are easy for the team to over / through and therefore they can come up with a good and fair estimate.
 

Visible Signs that you need to split your story:

• The team expresses great risks in the form of new technology or external dependencies.
• There are many concrete acceptance criteria. It determines itself what many are, but my guess is more than the 10th
• It takes you more than 5 minutes to explain the essence of Story to the team.
• The team estimate more than 5 story points. 

 

 

Stories Rate

When you break a story, it often occurs that the total estimate rises. It might seem like a silly idea to split now when it comes to "cost" more! 

A high estimate is the uncertainty. Then an estimate of 13 does not just mean 13 story points bum! This means 8-20 story points. Most go to get as accurate plans as possible, so therefore gives a splitting sense. And it may well be that on paper it looks like a bad deal for the PO but he achieves is security. Security to estimate holds. Security that he gets what he wants and that gives business value. And who would not like to have it.
 
So you exchange a small estimate of great uncertainty for a larger estimate of low uncertainty.
 
So my advice to you as Product Owner is to make sure that you make small manageable stores, for both the team's and your own fault. The extra work is well spent.
 
Happy splitting!



Reference : http://blog.devoksne.dk/user-stories-del-og-hersk/

Scrum Master Skill Set

i was going through some article on Aglie Scout and found this very interesting skill set of Scrum Master which become very near to my heart so i plan to share with my readers 

 Top 10 Personal Skills for a Scrum Master:  

• Servant Leader – Must be able to garner respect from his/her team and be willing to get their hands dirty to get the job done

• Communicative and social – Must be able to communicate well with teams
• Facilitative – Must be able to lead and demonstrate value-add principles to a team
• Assertive – Must be able to ensure Agile/Scrum concepts and principles are adhered to, must be able to be a voice of reason and authority, make the tough calls.
• Situationally Aware – Must be the first to notice differences and issues as they arise and elevate them to management
• Enthusiastic – Must be high-energy
• Continual improvement - Must continually be growing ones craft learning new tools and techniques to manage oneself and a team
• Conflict resolution - Must be able to facilitate discussion and facilitate alternatives or different approaches
• Attitude of empowerment - Must be able to lead a team to self-organization
• Attitude of transparency – Must desire to bring disclosure and transparency to the business about development and grow business trust

Technical Skills:

• Understand basic fundamentals of iterative development
• Understand other processes and methodologies and can speak intelligently about them and leverage other techniques to provide value to a team/enterprise
• Understand basic fundamentals of software development processes and procedures
• Understand the value of commitments to delivery made by a development team
• Understand incremental delivery and the value of metrics
• Understand backlog tracking, burndown metrics, velocity, and task definition
• Familiarity with common Agile practices, service-oriented environments, and better development practices

*The above technical skills are nice-to-have, but not necessarily required!