You have a newly formed team which needs a Scrum Master. Two team members of that team want that role. They have equal amount of experience, and both know Scrum fairly well. They both really want it. They ask for your advice. How do you help them? Here are a few ideas.
Have you started working with a new team? Maybe you’ve been working with your team for a while and would like to turbo-charge interactions within your team. People have unique characteristics, they are motivated by different factors, have unique natural talents, learned skills, and personal passions. Here’s how you can utilise these characteristics to get to know them at a whole new level.
AGILE, PRODUCT OWNER
How to combine the best elements of user interaction design, interface design, customer needs, customer value and the organisation goal (commercial perspective) into a user story? That’s quite a list. User stories are supposed to be concise, small and clear. Here’s how you can combine all these elements into a very good user story.
You’ll find tools that help you create over-complicated user story hierarchies. You don’t need to use the features just because someone has built them, or some consultants have suggested it – because that’s how they’ll get to bill for longer. How many levels of a user story do you really need? Here are some thoughts from Mike Cohn.
Should the Scrum Master work as a dedicated Scrum Master? If that’s the case, how many teams should a Scrum Master work with at the same time? What if you don’t have enough work for a full time Scrum Master? Should they do a secondary “job”? Here are some thoughts on this.
You probably a know a few Retrospective techniques. We’ve covered a few of those in the previous issues. Let’s say you want to become an effective facilitator – what are some of your crucial responsibilities? Well, you need to help people be positive and help them explore insights. You need to really become a professional facilitator, right? Here some 10 responsibilities you shouldn’t ignore as a facilitator.
NoEstimates continues to draw attention, some for and some against. Recently the prisoners of the movement stated “Getting better at estimates is like using time to plan the Everest climb instead of climbing smaller mountains for practice.” Is this the case? Here’s a critical look at this premise.
Have you been practicing Kanban for a while, and you feel like it has lost a bit of steam? Have you added new team members who’d do well with a quick check list? Do you need three quick tips to do a quick health check on your Kanban system. Here you go.
If user story just a smaller and concise version of a use case? Why would you use one or the other?