What makes a good ScrumMaster 2

Scrum has only three roles: the Product Owner, the Scrum Master, and the Dev Team.

Scrum names three roles because the framework needs all three roles, they are all as important as each other and all are vital to the successful implementation of Scrum.

But of the three key roles the Scrum Master is the least understood and most easily confused.

Is a Scrum Master necessary?, is it full-time?, is it just another name for a Project Manager?, or a team manager? Can we manage without one?

These are just a few of the questions posted endlessly in forums and asked in organisations newly adopting Scrum.  [Spoiler – the answers are that if you are doing Scrum right then: Yes, Yes, No, No, No.]  As for the mandatory “but we ignored x, y, and z and Scrum worked for us” follow-up comment – I’d say something may have worked for you but it wasn’t Scrum, and unless you can describe what you did in a framework that can be clearly described and reproduced successfully in a variety of situations then your justification for not following rules doesn’t help anyone else. Which brings us neatly back to the need for a Scrum Master to help adopt Scrum correctly. Once Scrum is established, the teams are performing well and have confidence in the Scrum framework then the burden on the ScrumMaster diminishes, but in the early days don’t underestimate the effort required to build a Scrum team, especially in an organisation new to agile.

Confusion

Let’s start with some of the things they are not:  They are not the manager of the team; they are not a project manager; they have no authority; they are not an all knowing Jedi master; they are not senior to the dev team or senior to the Product Owner, and they are not the Stig.

The goal of a Scrum Master is to help the team improve.  

That’s all, they have no responsibility for delivery of a project, or the quality of code, or testing or reporting, or enforcing good practices, they have no line management responsibility. Their one and only responsibility is to help the team get better.

This can be achieved by teaching, coaching, facilitating, and removing impediments.

Scrum Master

It is about influence not authority.

To be a great Scrum Master you need to be the sort of person who gets as much satisfaction from enabling a team to achieve, as you do achieving something on your own – and be content not getting any credit for it, because you won’t. You must also be willing and happy to surrender control to the Product Owner and the team.  The ScrumMaster title is a reflection of responsibility not rank. It will quite often be necessary to sit back and watch a team make a mistake, because they will learn far more from that mistake than from you stepping in and forcing them to do it your way.

A Scrum Master is an advisor not an instructor. 

A good Scrum Master is a coach, ideally they have a good understanding of good practices, hopefully from practical experience. A Scrum Master that “has been there and done that” is a huge bonus as they can bring experience as well as theoretical advice. The caveat being that they give advice – not impose their own way of doing things.

It may be the SMs role to coach a team on XP skills; or automated testing; or on public speaking; or negotiation skills; or help with story writing; whatever the team needs to improve. It also involves teaching the team Scrum practices and helping them identify where they can improve. The ScrumMaster will likely coach the team and the Product Owner and hopefully broaden this scope to other parts of the organisation over time.

But this is all done without authority, the SM has no authority over the team or the PO, the SM cannot make the team follow Scrum processes, but should help the team understand why the processes should be followed so the team can then choose to follow them.

A ScrumMaster may encourage adherence to rules the team has committed to follow, but cannot impose rules on the team. A Scrum Master should never tell someone to do (or not to do) something, more often you will hear them say “have you considered doing x” or “have you considered the implications of not doing y”.  The SM is not responsible for rules being followed.

The ScrumMaster as a coach

A Coach is probably the best analogy for what a Scrum Master does. If you compare them to what a sports coach does for their team. They encourage; they watch and they advise; they guide; they protect from distractions; they can be constructively critical; they identify ways to strengthen the team in skills or teamwork; they push the team to perform to their best; they strive to improve. They also coach the team to manage resources to ensure the right people are assigned to the right tasks on the team – you likely wouldn’t put your star striker in goal, for example, but you may encourage a back-up to be used sometimes to avoid critical dependency issues later.

A Sports coach is usually someone who has a deep understanding, and appreciation for the sport and wants to share this with the team, sometimes they are previous players, sometimes just armchair experts.

How Many teams can a Scrum Master work with?
*An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things no one previously thought possible, within a transformed organization, consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.

*(Taken from Mike James ScrumMaster Checklist)

The ScrumMaster is a Scrum Expert

To be a good ScrumMaster you need to be an expert on Scrum, you need to know the framework, but that is not enough. You also need to understand it and to have applied it, Scrum is as much about application as it is about knowledge. To coach it effectively you need to believe in it and be interested in it beyond just training, it is on-going learning, developing new skills and ideas, and discussing it with others, a ScrumMaster should be a Scrum enthusiast.

The ScrumMaster as a radiator

A Scrum Master is also responsible for encouraging the team to be transparent, for radiating information to the wider community, this might be task boards, training, printed roadmaps, burndown, velocity charts, a variety of graphs, even a publicly displayed backlog. Scrum is about transparency and sharing information both good and bad is crucial.

The ScrumMaster as an evangelist

A ScrumMaster is also responsible for spreading the understanding of Scrum to the wider community, for helping the organisation understand the need for continual delivery, and how and why Scrum Teams work the way they do, helping the organisation interact with the Team, and understanding why they can’t interrupt them or why they can’t change direction or add work mid sprint.

Top tips for being a ScrumMaster

Independence – To be successful you need credibility and respect, that is far easier if the team doesn’t know you. You start from a clean slate.  If you move from being a dev to being a SM on the same team you take with you a lot of past preconceptions you of them and them of you.

Objectivity – Get involved enough in a project to understand it and to advise, but not so much you are taking charge, your role is to coach not lead, if you feel yourself leading step-back. A lot has been said about having no authority but you do have a lot of influence, try to use it to influence the team to get better not to influence the product.

Take it slow – Improvement comes slowly, try not to change too much too soon, create an environment where improvement is encouraged, and change things one at a time. Not all changes are positive, and not all changes have an immediate impact, but don’t stop trying to improve.

Teamwork – encourage teamwork above all else, a team that works well together will make everything else easier.

Keep quiet – If you are talking then others are not. The Scrum Master should be encouraging the team to discuss and resolve problems not solving them for the team. Before you speak think twice, take a breath and guide don’t direct.

Summary

Scrum is fairly easy to understand but is extremely difficult to master, and being a ScrumMaster in my opinion is a very tough ‘easy job’.   The expectations are high, the responsibilities unclear, and the rewards are indirect, and because the goal is improvement the job is never done.  At times it may appear to look easy, but I can assure you that when it looks easy it has probably taken a lot of effort to get to that point.

Advertisements

The Confusion Over Story Points.

In my last post I referred to the myth that Scrum Masters can make themselves redundant, the other most common and persistent myth I regularly hear is that Story Points are a measure of complexity.

No, no, no. Story points are just about relative size.   That’s it, nothing more. There really is nothing complicated about it.

It is all relative

A small ‘simple’ task is not the same as a large ‘simple’ task.  And a small ‘complex’ task that I can have done in a quarter of the time of a large ‘simple’ task does not warrant a higher story point estimate. It makes no sense to estimate that way.

My advice when estimating stories is to pick a cross section of stories, pick around a dozen typical stories of varying: scope, sizes, complexity, uncertainty, and any other factors that might affect the time and effort involved. Discuss them and get a feel for the stories and then sort them smallest to largest.

Next take a story in the middle and stick it in the middle of a white board on a horizontal line drawn across the board.  Next take each story and estimate how much effort relative to the stories already on the board mark each story on a number line, hopefully you will get a flow after a while. E.g. The next story is 3/4 the size of the first so i put it 3/4 of the way between the end of the line and the first story.

Story Points 1

When all your stories are on the line pick a scale that you think looks right.  Just Try it and see, each set of stories will have a different distribution, if you initially pick a number too low and things feel squeezed, just try again.  E.g you pick the story in the middle and using Fibonacci numbers call it 13pts where does this leave the rest? Do they fall easily into other Fibonacci numbers? stories around a 1/4 the size of the first would be a 3 and so on.

Story Points 2

That is now your scale, and regardless of how your definition of done changes, or the team changes, the relative scale remains.

If you are lucky enough to have a team room with space to leave those stories up on the wall on the scale line that’s great, if not then take a picture.  From now on when estimating any story you can say how does it compare to ‘x’, x was a 13pts and this is similar, or this is 50% bigger than ‘z’ and that was a 3 so this is a 5pts.  By keeping everything relative to the initial stories and you keep the estimates consistent.

But what about complexity?

Complexity, and uncertainty, or time consuming interactions between layers or departments are all just considerations that affect the size. “That task is complex it may take me a bit longer”, “That task is unclear I’ll need to take some time to understand this aspect of it – it will take longer” all we are saying is that it is just relatively larger, there is no trick to it.  It might help make life easy to say – this story looks very similar to 5-point story ‘x’, but has some uncertainty (or I’ll need to liaise with another department) therefore we’ll estimate an 8.  It is the fact that complexity adds time that makes it a bigger estimate not anything else, it is just another factor in comparing the relative size.

Story Points 3

Comparisons are so much easier than raw estimates.

When estimating new stories all you have to do is pick a story and say: “will this take longer than reference story x?” or “will it be less than reference y?”  with enough reference stories there should be a suitable comparator to find a similar sized story and give it the same points value or a bit more or a bit less based on a considered factor. After very short time you will instinctively know the scale and estimating becomes quicker and easier. Your refining becomes a series of comparisons e.g. “this involves more testing than story x” or “it is like ‘y’ but with a bit more to the UI” etc.  Comparisons are so much easier than raw estimates.

What about ideal hours or ideal days?

Some teams use ideal days or hours for estimates but that is subject to change according to the team, the team changes and the estimate changes, what if someone is off sick or on holiday? and more confusingly it implies a commitment to a particular amount of effort, what if your DoD changes and suddenly you are writing automated regression tests for each story, suddenly the scale us blown, but a relative estimate is always relative.

Sometimes after a while teams begin to drift, it may be worth having a refresher of the initial stories and initial estimates just to calibrate your estimates periodically, maybe even add new reference stories to keep the scale fresh.

Just remember it is all relative

Just remember it is all relative, and then it is easy!

What makes a good Scrum Master?

The Scrum Master job is proving to be quite an enigma, management seems to struggle to see the value, there are numerous myths about how a Scrum Masters goal is to make themselves redundant which further fuels the confusion of management as to whether they are even needed, others have a view that a Scrum Master role is part time, and a Scrum Master can effectively cover 2 or 3 teams, I even saw an advert recently for a Scrum Master to have 5 teams!

There are endless discussions on Scrum forums about a split SM role a mix of Dev/SM or tester/SM or even Product Owner/SM and each time I wonder if they don’t understand the purpose or the value or have simply had some really awful SMs and just see the role as a glorified meeting chair and someone to do the admin. A good Scrum Master can have a huge impact on a team.

Then the flip side of that is that the job description makes a Scrum Master seem relatively straightforward, but anecdotally in the company I am currently working with there are 7 scrum teams and in the last year they have had 10 people attempt the role, mostly they were just covering one team. The attempts have been a Dev/SM, a tester/SM, a former PM, a Product Owner/SM, a former Dev and a dedicated SM covering 2 teams.  Generally speaking the attempts have been unsuccessful, and never as a result of a lack of Scrum knowledge, or the ability of doing their previous role, those selected were generally senior and very capable, but clearly that alone is not sufficient.

Some struggled to balance a split role, some underestimated what the role of SM involved some were too soft, some were too hard some felt that they could not effectively perform a split role and wanted to revert to their former role, others were simply not a good fit.
It seems an odd thing to say but in my opinion the job of Scrum Master is as much about personality as it is about skill set.

So what makes a good Scrum Master?  My summary would be two ears and a very hard nose. Most of the time is spent listening, being an advisor, scanning for problems, counselling and coaching, offering guidance when asked. Is essence making use of your ears.  But less frequently you need to stick your nose in – even when not invited, and you may get resistance. You may need to challenge senior management, or actions in the team, you may need to intervene in conflicts or resolve difficult impediments, you may need to resolve disputes, and you may need to challenge the team. Hence the hard nose, you have no authority so this is often simply only backed by your personal gravitas, your confidence and the credibility you hold in the team and the organisation.

But even then there is so much more to the job which may explain why it is such a difficult role to do well and may explain why the number of job adverts for Scrum Masters has rocketed in the last few years.

Gravitas, confidence and credibility (and trust)
To be effective you need to be able to communicate with senior management as one of their peers, you need to have the confidence to challenge their decisions and offer advice and guidance for this you need credibility.

On the flip side though, you need to work closely with a team. To be effective they need to see you as one of them, they need to trust you, to be open and honest with you. They need confidence that you will act in THEIR interests and that you are there for them.
They too also need to respect you, if you are giving them advice they need to believe you know what you are talking about and for this a sense that you have been there before and got the t-shirt really helps.

Objectivity
I work with a fantastic Product Owner, he is very well respected by everyone and prior to my joining he did a split PO/SM role. He will be the first to tell you this is a bad combo, but he managed it remarkably well, but had the good sense, the confidence and the credibility to know when to ask for help. (As an aside I think a willingness to ask for help and knowing when to ask is a strong skill that far too many people lack or see as weakness).
He and I see the roles of PO and SM as a partnership, we work very closely together, but that is not to say we don’t challenge each other regularly.

He considers the most significant attributes I bring to the table are independence and objectivity and I am inclined to agree. By being slightly removed from the team and the project, not having responsibilities, or deliverables and not being personally invested in the code or the design I can bring an independence in my advice, my suggestions are not encumbered with an agenda or a vested interest, just a desire to improve the team and do the job better. This may be one explanation why the SMs plucked from the team have struggled.

A final problem that a Scrum Master faces is that there is no measure of success. A successful project is down to the Product owner, he takes the responsibility, shared with the team.  Problems in a team reflect badly on the Scrum Master, but when a team is doing well the reverse is not true, the credit – quite rightly goes to the team. 

Think of a sports star and his coach, if a sports star does well he is showered in praise, if he performs badly he fires his coach.  The team is the talent, the coach is responsible for enabling them to perform at their best. The reward is seeing the team do well.

My final comment is to address the myth that a Scrum Master should be striving to make themselves redundant. Again I’ll compare to a sports team, if you pick the best team in any sport, they have reached the pinnacle of their profession – top of the league, winners of a cup. Do they then declare they no longer need a coach? I doubt it, even the best sportsmen and sportswomen at their peak have room to improve and it would take shocking arrogance to believe there is nothing more that can be improved or learned in any profession and in particular a team context. 

The myth that voluntary overtime is commendable

I was chatting to a friend last night, he is a manager of an IT department and I used to manage a software department before I became a Scrum Master so we tend to talk a lot about management techniques and especially how a lot of the successful traditional techniques map to Scrum. 

It is performance review time and the topic of conversation got around to a frustrating belief by some staff that working long hours without being asked is something that should have an implied reward.

I can’t speak for all managers, but for the two of us I can say that we consider it to be the opposite, when someone works late on a regular basis without being asked, we see that as a red-flag. Certainly not to be commended and very likely a sign of problems.

I used to pride myself on being a good manager, I felt I was fair and sought to do what was best for my employees and the business, sometimes it was a fine line and often not easy. But one of my strongest principles was to be fair. I would never assign someone more work than I felt they could handle (that is not to say I didn’t seek to challenge them), I would always check they felt it was fair and I would always say very clearly that they should come back to me if they had problems, and I would review on a regular basis usually weekly.

As a Scrum Master the roles are reversed, the team tell me what they feel they can commit to and they review with each other on a regular basis (at the daily stand-up) and keep a track with a burndown chart.

So in either of these scenarios is there scope for voluntary unpaid unrequested overtime? (The answer is No)   In the case of assigned work if you cannot get it done in the allotted time then it is a failure of management – either I have incorrectly assessed the amount of work or I have misjudged the individuals capability to do it, and unless I have opportunity to be aware of that I cannot correct it and the cycle will repeat. The same is true in Scrum, the model is built on empirical evidence, if your estimates are low you learn and adjust next time, working extra to meet a commitment hides problems and perpetuates failing cycles, it also causes imbalance in the team, makes pair programming difficult and sends mixed messages to others. Very simply as a manager or a Scrum Team you cannot fix a problem you don’t know about, and commitments are achieved as a team.

So should you reward someone for working late, for their dedication and loyalty? or should they be reprimanded for their lack of transparency, their lack of courage in challenging an inaccurate estimate, their failure to communicate an excessive workload or lack of knowledge/training/understanding to achieve the objective?

If I ask you to work overtime I will do so with a very heavy heart, I know that it is not good for you, or the business and any gain is short-lived. It will only be in exceptional circumstances. So if you do overtime which conflicts with our team plans or expectations please don’t expect to be rewarded. That may sound harsh but I value communication far more than you giving extra to offset a failing elsewhere.

 

The ‘Zone of Acceptance’

One of the challenges of an Agile Coach, or anyone in a management or leadership role is establishing what I have seen referred to as the “zone of acceptance” for individual team members.

The Zone of Acceptance is a term for the tasks an individual sees as something they are prepared to do as part of their job.  This can relate to tasks, overtime, meeting attendance and more.

In a traditional model where work is explicitly assigned, this took the form of a team member saying “that’s not my job” when asked to do something on the periphery of their role. E.g. being asked to write documentation or attend a meeting outside core hours.  This is a confrontation that can be handled directly, the team member can be coached to broaden the scope of their ‘zone of acceptance’ and have it explained that sometimes responsibilities extend beyond core hours or core responsibilities.

However, when you move to agile it becomes much harder to deal with.

As an aside, in my house I will sometimes come home to find the kitchen bin full or overflowing, if I ask why it has been left like that my wife with very matter of fact reply – That’s your job.  I don’t doubt that it is, but it is a hard line, if I want to challenge it I can, the responsibility is clear.  But conversely my behaviour in a different situation is far harder to manage. My wife may ask me to change our daughter’s nappy (or diaper as my wife calls it), I will generally willingly comply, but I very rarely volunteer.  I would never say it is not my job, but by subtly avoiding doing it I am implicitly saying so.  She can ask on a regular basis but that in itself undermines the equality and self-organising nature of marriage. The reality is that she is not asking me to take responsibility, nor is she demanding assistance, but my help is appreciated.  What I need is to broaden my ‘zone of acceptance’ and to be more proactive in my support.

The same becomes true in a Scrum team, if I were to hear someone say ‘that’s not my job’ or “I’ll hand that to a tester” or similar comments, they can be challenged. But far more common is seeing the team members forming natural silos for work, an often agreed line in the sand where work is divided and not challenged.  They will avoid tasks they are not interested in or don’t see as their role, find excuses for working on tasks they see as theirs and in some extreme cases work on something outside the Sprint to avoid picking up a task that doesn’t fall into their zone of acceptance.  This behaviour may not even be visible, a Scrum team can actually be very productive forming mini-silos, but that doesn’t make it right.

I see the role of a Scrum Master to challenge these silos, to encourage team members to broaden their zone of acceptance, and to get the team to inwardly think that it is their responsibility to get involved in Story writing, and coding and testing and be active in meetings, to volunteer to write documentation and present the Sprint Review, and to challenge those that don’t.

“But I’m a tester I don’t know how to code” – is a common argument. My response – “So what!” a lot of coders I know would benefit very much from having a tester on their shoulder asking if they had considered this case or that case, challenging the use of TDD and actively engaging in what and why things are being coded even if they don’t understand the code itself.  And perhaps more controversially the opposite is true, having a developer sit on the shoulder of a tester and see what and how and why certain tests are performed can help improve the way a developer writes code. I think we can make passable testers of most developers and vice versa, teams should want to challenge boundaries.

By this I am by no means suggesting that we create a team of jack of all trades – I am actually very much against that, expertise should be encouraged and my view is that testing and development are very different skills and expertise in either should be valued. But my view is that the comparison of skills needed for a sprint will often form a huge amount of overlap. If a product or sprint is a puzzle, chances are that there are a few parts that require specialist ‘Blue’ or expertise in ‘Red’ skills but the majority of the work is shades of ‘purple’ something that does not require expertise in either.

purple jigsawBut now what? We understand the problem, we know it is hard to spot and hard to challenge, so how do we expand the zone of acceptance?

The first step is nearly always acknowledging there is a problem. Discuss it with the team – maybe as part of a retrospective and see if they recognise it as a problem. Let the team find ways to solve the problem. Once they see themselves as a team it becomes easier as they will be seeking ways to help each other rather than for the easy way out.

One team I work with identified this themselves and their solution was to put a sign on their task board that said: “Have I done this before?” And another sign that said “Is this on the critical path?”

have I done this before

The idea was that when selecting a task to do the team member would stop and think: First whether they were taking a task that someone else could take and learn that task – or maybe they could pair and teach someone else; and secondly is this the next best task for the sprint or am I taking an easy option?  It is a written reminder and a challenge, and a challenge I’d encourage the other team members to make.

This barely touches the surface of this particular problem, and I’ll no doubt come back to it, but there should be a desire by the individuals on a team to (sensibly) broaden their zone of acceptance, for the focus to shift from what is the next best(or easiest) task for me to what is the next best task for the team.  And more significantly for this to be supported and encouraged by the team; the Scrum Master and the organisation.

What makes a good ‘Story’?

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable


Independent

Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.

Negotiable

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details.

Valuable

A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.

Estimable

A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation.

Small

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope.

Testable

A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive.

Backlog Refining Crib Sheet

Purpose of backlog refining:

  • Prepare stories for planning
  • Provide Product Owner with a rough estimate to aid their planning
  • Breakdown epics into manageable stories
  • Verify stories take us towards our goal and fit with our vision.
  • Identify Spikes

When?

Refining should happen for at least 2 hours each sprint to stay on top of the backlog and ensure that there are sufficient stories estimated to be ready for planning – preferably a number of sprints ahead. (early in a project more time may be needed to get ahead)

Who?

  • Product Owner
  • Scrum Master
  • Entire Development Team

Before you begin

Product Owner should order backlog by his current perceived priority.

Agenda

The Agenda is the backlog, move through the stories one at a time estimating or breaking down epics until the timebox has expired. (or all stories in backlog are estimated)

Timebox

The Scrum Master (or designated facilitator) should ensure that the meeting is time-boxed. Refining is tiring and has taken us away from the current sprint. Keep to the allocated time and schedule another meeting only if it is necessary.

Focus

The Scrum Master must ensure the discussion remains on topic. If a discussion is getting into deep detail on the solution it is likely you are off topic. The goal is to give a rough relative estimate, keep discussions to a high level. If the answer to a question wouldn’t alter your estimate you probably don’t need to ask it.

Estimates

There are a number of techniques for estimating PBIs, some teams use relative story points, some use T-shirts.   The value in the estimates is to the Product Owner and not the team – although there is some indirect benefit.

Story estimates should not be confused with Task estimates which occur at Planning Sessions.   Estimates should be of the relative size compared to other stories (it is not a measure of complexity). Many teams find it useful to identify an initial series of stories to use as your benchmark, or to create a datum to guide estimates.

An proper estimate is the relative size of a story to meet the definition of Done, including any requirements for documentation, testing and delivery – i.e. the package not just the coding.

Note: Estimating is tough! But it is not unique to Scrum, there are dozens of books on estimating software development. Scrum takes a view that estimation by a cross functional team is better than estimation by a single individual.

Story Breakdown

The refining meeting will often identify ‘Epics’ or stories that are too big or complex to estimate or to fit in a single sprint.  A skilled ScrumMaster can help the team breakdown stories into smaller slices that still have business value, it may be necessary to arrange specific story-writing sessions for some of the more tricky stories. There are a number of different techniques that can be used to break down stories.

Note: Story writing is tough! It will take time to get used to story writing and to find a level that suits the team, it is an acquired skill, and there are many techniques. A good Scrum Master may make the process a little easier.