Putting scrum and user stories into practice while helping the team
I've recently joined a team as a "proxy PO", the principal PO also being in manager position.
I have some questions about problems I encounter, but before let me give a bit of context:
One of my task is to introduce improved story slicing, and for good reason: the company in general has been going through a restructuring phase as of late, and while the dev team is diligently at work in the department I am working in, work loads are heavy and precise definition of what and why things have to be done is lacking. Burndown charts are, well, of the charts (50% of stories "done" per sprint, average over the last year). The team is positively supporting though (officially want to see some change, members against did leave recently), as is the PO and the Scrum Master (external contractor, lots of experience), and there is some palpable doubt concerning agile methodologies but a will to implement it anyway. The end product is lacking, and the motivation is apparent but dwindling. It's fair to say everybody does her or his best though. Typical ceremonies are in place such as review, retros, dailies. There are three sub teams, one of which is offshore. We use the atlassian suite for the tooling.
My question is simply: how can I implement a good slicing strategy?
In the first months in this position, I noticed that all the user stories where what I'd call pure technical tasks (create a db table, migrate a server, you name it). I posited after a number of talks that, to have better sprints and better understanding of the product value, we could try devising stories as seen from the user/stakeholder point of view, and place tasks under those.
So, in the past the team would have had "create sql table" and "create UI" as stories, and now with my suggestion we'd have "Show me a list of songs" as the main story (= which brings value to the customer), for example, and I'd keep the technical stories as tasks to be assigned under the main story (= 1 story, with 2 tasks below it). Only "rule": the story is not complete until the tasks below are not solved, and as POs we need to slice the story in such a way that it is doable ideally within one sprint.
Here, problems started to appear: it turns out that the tasks can be assigned to different sub teams. One could go offshore, one could stay local (but both contribute to one single story). Because we have an older and weirdly configured version of JIRA, you may estimate the main story in terms of story points (our agreed currency), but not the tasks (no fields for that, which is a big no-no for our PO). Hence, the following critics appeared:
1. The PO tells me he cannot clearly see how many points are spent per task (since in our system, only user stories carry story points); say that some tasks are going to the offshore team ( a contractor), he understandably wants to know exactly how "many points they are capable of doing" (note, they run their own scrum locally and deliver reports often). The method of using tasks, because of our JIRA problem, does not satisfy his need.
2. Most importantly, some team members have expressed that this is way too complicated. They would cope better without any tasks, so I was told. They'd want to have it back as it was before, so an idea emerged which is to treat user stories as tasks and introduce a new hierarchy level over the stories. Basically, it's about taking the user story => task model and moving it "one up", if you see what I mean. I feel this is a step in the wrong direction but I am looking for consensus and advice on that; it may be decent, just would not have the "correct" names after all
3. One important aspect I wanted to introduce is the handling of velocity. Since sprints were not satisfying in terms of amount of stories completed (hence, no visibility), my thinking was: let's say that if the user story at the end of the sprint is not finished, we simply do not count the number of user story points into the velocity for the next sprint. For the PO, this is a huge problem, because it is unfair for the dev team who has worked a lot and is not rewarded properly. I expressed that story points are not to be seen as a reward, and they should just be taken at face-value, which is, to me at least, as an indicator of capacity; in the sense of: you cannot finish a story within a sprint? Well take that into account into the next planning by reducing the velocity. So was my thinking. The PO and one other analyst have expressed their utter dislike for the velocity, and this was made all the more difficult as a discussion by the fact that an article made the rounds in the company according to which agile employs a lot of buzz words and misnomers, with the main culprit being the velocity.
4. Finally, although openly declared as in favour of agile, I sense deep doubt about agile or scrum in itself in PO circles for this team. I've been told by one member, quote "agile is classic project management with new clothes" and "I'd prefer to ask each and every one of the developers for estimates in hours, then I'd know where I stand" and "let's go back to basics, list tasks and we are better off". I'd admit, while appreciating the person and absolutely respecting his experience, that this was somewhat disturbing to me. Add to that the Scrum Master, who is experienced and intervenes as a contractor (not in-house), who has views very much in favour of agile, stories, velocity, but whose views are often contradicted by the PO/Manager (who assumes final authority on all things - which I can understand in principle I will admit), and you get a picture.
So all in all we've got good people, definitely a good boss with great attention to well-being, and a company which in the wake of internal reorganisations is exerting a heavy pressure upon the team (shielded by the boss, I want to make that clear because as wary of agile as he may be, he does act in a courageous way I want to stress that).
I've detailed the problems, my approach may not have been the best, how would you advice to proceed in this case to, simply put, make life better in the team and achieve clear goals, reduce workload and delivery value?
I'm going to start by commenting on a common topic in your items...Story Point estimations. Estimates, regardless of how you do them, should not be used for determining team success. Estimates are based upon a guess using the knowledge at the time of the estimate. After work begins, it is typical to uncover information that would have affected the original estimate. Estimates help the teams to estimate how much work they can pull into their forecast (Sprint Backlog). But after that occurs, the estimates are no longer useful. If you want to determine the team's effectiveness you should use the value that they are providing. An example is a quote from a construction company to remodel your bathroom. The will give you an estimate of how much it could cost to complete the work and the length of time it will take but they say it may be more or less based on what they discover while doing the work. On after the work is done can you actually know how much it costs or how long it takes. Same goes with software development. You really do not know how long it will take to do the work until it is done and you do not know how much it will cost (wages, expenses, time) until all the work is completed.
1. As I mentioned above, the PO is using inappropriate measures to determine progress. My comments above apply to anything that you estimate.
2. I agree that this is a bad idea. I have worked with many teams that do not use tasks. If the teams are actually doing their Daily Scrum, then they are planning their work every day which is much more efficient. If the team introduces tasks before work begins they are estimating the tasks needed. Refer to my comments on estimates above as they apply here as well.
3. There are many opinions about velocity in agile. Most of them are based on the way that it is calculated. There are just as many opinions on what works as there are on what doesn't work. Velocity can be calculated and used but there is no magic way of doing it that works for every team in the world. Even within the same organization velocity can be measured differently by team. As to using Story Points as a reward to the team, I agree with your opinion.
4. This is not atypical in organizations even if agile has been used for a while. This is something that the Scrum Master should focus on as part of his responsibilities to the PO, Scrum Team and organization. It shows an lack of appreciation for agile and Scrum. You might mention your concerns to the Scrum Master.
On the whole I think you have some good opinions on how the current process is not beneficial to the organization. Work with your Scrum Master to incrementally change things.
@Daniel Wolff, After reading through your post a few things that came to my mind are: Do you guys have a Sprint Goal each Sprint, or is the current practice to load the Sprint with stories and try to accomplish it?
My question is simply: how can I implement a good slicing strategy?
It sounds to me that your team is one among many when it comes to the functionality being delivered for the end product? Is this a fair statement? Or does your team have the ability to directly influence the product? i.e. Does your team own the Product?
I sense deep doubt about agile or scrum in itself in PO circles for this team.
I can understand how you or your team members feel about this. Agile is not necessarily a magic wand, that when waved, will solve all the problems of waterfall, reduce cost, and deliver fast products and neither is Scrum. The practice of Scrum is to help teams inspect and adapt based on what they've already learnt. Every organization seems to be jumping on to the Agile bandwagon without having a good understanding of what it is, and expects results. The common misconception is that Agile is Scrum; Let's have a Daily Scrum, 2 week Sprint, Refinement, Sprint Review, Sprint Retro and voila! we're Agile.
That's where the problems start, because the work is being done exactly in the same manner as before with Scrum placed on top of it. The result is just a complex, chaotic mess. It's usually neither Scrum nor being Agile.
Add to that the Scrum Master, who is experienced and intervenes as a contractor (not in-house), who has views very much in favour of agile, stories, velocity, but whose views are often contradicted by the PO/Manager (who assumes final authority on all things - which I can understand in principle I will admit), and you get a picture.
This is a classic case of command and control and something that supports my previous comments. Even favoring stories, velocity etc does not help unless it serves the purpose it was intended for. Everything is a story does not support the cause of being Agile.
Would you be able to ask your Scrum Master why we should be writing stories? and, If you wrote stories, would that make you Agile?
An example is a quote from a construction company to remodel your bathroom. The will give you an estimate of how much it could cost to complete the work and the length of time it will take but they say it may be more or less based on what they discover while doing the work. On after the work is done can you actually know how much it costs or how long it takes. Same goes with software development. You really do not know how long it will take to do the work until it is done and you do not know how much it will cost (wages, expenses, time) until all the work is completed.
@Daniel Wilhite, Good example on estimates and emergent work!! I am going to use this. :)
That example is real life for me as I have someone remodeling one of my bathrooms right now. But anyone should feel free to use it or adapt it in any way relevant. I came up with that because my Dad used to do handyman work on the weekends for some extra money and the estimate/completion difference has always stuck with me.
Thanks for the answers.
David: I do absolutely agree with the idea of the metric of story points not being a reward. I see story points as an easier way to give estimates, and velocity as a measure of capacity. But that’s only my view. The PO does see both those concepts (which have been apparently introduced to the team a good few months back with their agreement) as misleading and has from the get go expressed doubt about those. I wasn’t there to witness the situation prior to that, but I am told it was dire hence the original need for change. My frustration comes from the fact that I firmly believe these concepts have not been introduced or explained to their full potential and are now being criticized for actually bad reasons. Of course with a misleading belief velocity and story points can be toxic.
Steve: the team is not owning the product. In fact, we are indeed in a command and control situation where the actual value can be questioned up to a point, it moves top down. Now there is a parternalistic kind of well meaning way of doing that, but the fact remains, in my opinion.
In both answers I was told to lean on the scrum master, and I agree in principle. The situation is however such that the scrum master has progressive views and de facto steps on the toes of the PO who is only willing to go so far with those concepts. It has some aspects of a background power struggle, but I’m not even sure that this is being done consciously, or that there is even bad blood behind that. I’d say if push comes to shove, there is readiness to axe the SM who is a contractor. I do however appreciate his input and do believe he at least asks the good questions.
I do sense however a slight and subtle rejection pattern in the team concerning some methods which have been put forward.
Again, the situation is one where agile is starting to be pointed at as a kind of disturbing thing, and actually, I even believe that this is not properly agile that is going on there. There is every possibility right now I believe that it’s going back to waterfall only with agile names put on all things.
I am looking for steps to alter the current framework to match the team and the PO better. My main worry right now is that delays totally fly out of the window and clarity about things to do in a given project is lacking.
It sounds like someone in upper management read an executive brief online that said agile would solve all problems, make things faster and deliver features more often. I personally have not seen that happen. Yes it can solve problems but it makes problems more apparent in all cases. Yes, it can make things go faster and deliver features more often but it is faster delivery of increments of value in order to gain feedback more often to allow for course corrections.
I wouldn't try to alter frameworks as they are intentionally vague when it comes to process. Find ways to alter the processes such that it fits into the organization and still honors the framework. All of your suggestions and opinions seem reasonable to me. The question is whether the organization is willing to make the changes needed for success. Circumstantial evidence leads me to believe that they are not willing. That kind of attitude always leads to a failed attempt to transition to agile practices, at least in my experience. I will say that the fact your Scrum Master is contracted instead of hired is another sign that they aren't committed. That is unless there are a large number of the staff that is contract labor then this becomes a different thing as it is a common practice at your company.
One final thought on a passage from the Scrum Guide section that provides the Definition of Scrum.
Scrum is a process framework that has been used to manage work on complex products ...
Is the work you are doing complex in nature? Is it something where there are frequent changes in the problems being addressed? Is incremental delivery something that provides value? If not, I'd say that moving away from agile and back to waterfall/command-control methods might be a bad idea. It could also be the reason that agile is being viewed as it is. Agile is not needed in all situations and in some can introduce complexity.
Thanks for the feedback.
It turns out, on company board level, a decision to go all-in on agile was taken. Now, some departments seem to cope quite well with it. There have been quite a few departures in terms of personal, and budgets are extremely limited. That's the situation.
Now in the department I am in, the PO/manager is open to try agile, I really do believe. The SM being a contractor has more to do I think with available resources and departures.
Now the products we deliver do receive frequent change requests and are really incremental in nature, to answer your question. I have done waterfall, and I think scrum is an adequate framework for the situation.
The problem like I said is that the implementation of it is skewed. It cannot be possible to have sprints which deliver only just half of the stories put in it, and that over one year. So maybe points and velocity are applied wrongly, but then I am on the lookout for precise solution to that.
My own goals are:
- render the sprint predictable in terms of work that is being produced
- reduce pressure on the teams and reinforce ownership (the quality at the moment is lackluster, bugs are put under the carpet and so forth)
It cannot be possible to have sprints which deliver only just half of the stories put in it, and that over one year.
And yet according to you, that is exactly what is happening.
Just curious what the team discusses in their Sprint Retrospectives about their very consistent failure to meet their sprint forecast.
I think Steve had a very good observation - does your team identify a Sprint Goal each sprint that guides the work that they do?
Personally, I am a big fan of your approach to craft PBI's from a user perspective. In my opinion, most items that a team works on should somehow be customer-facing in nature. To not embrace such an approach is somewhat symptomatic of individual and technical silos that do not promote Agile.
Lots of good observations and advice already in this thread. I can comment further once I get clarity on the above.
It cannot be possible to have sprints which deliver only just half of the stories put in it
At what point during a Sprint does it become evident to the team that this is nevertheless going to be the case? What do they then do about it?
To answer the question above and address the point about sprint completion in both answers above: the teams consistently notices being on the wrong side of the burndown chart directly at the start of the sprint.
The Po is openly against velocity, and thinks story points are meaningless. I tried to address that by reinforcing the need to actually understand the value of 1 point. To agree of a common ground. That standard value has been lost. Now people feel punished because of the velocity and do the story point estimation without belief. I tried to explain that we need a metric for the capacity and that not achieving a story should lead to said capacity being adjusted in the next sprint...alas there is pushback. I have heard multiple times that in po and ba circles there is a very real desire to switch back to hours and man days, classic estimates. People strongly express the desire to be recognized for the task they do. So at the end of the day, conveying the user focus as being our central value is pretty hard for me since the focus is on one’s own task.
I believe this team needs scrum but is utterly unfit for it right now. So I will have to accept decision going the other way and try to introduce agile bit by bit. The team is well meaning but the resistances are quite strong.
To make things worse, we had a sAFE external consultant who came along (was working with another department) and tried to present his own concept in very directive terms (this is THE solution, something along those lines), which to me does not exactly help.
I think the only way is to run with this waterfall with agile clothes and bit by bit introduce new ideas. I really don’t see any realistic solution right now.
I feel like if your team could start delivering value in every Sprint, the "we need hour estimates" objection could be mitigated. I am getting the feeling that PO/BA is asking for that so they can hold people accountable to their estimates. I can hear these words.
You said it would take 4 hours and you have been working on it for 5. You must being something wrong.
The reason that the estimation process was turned away from hours is because you make your estimate(read guess) based on incomplete information. In my opinion this is the biggest contributor to why so many waterfall projects were always incomplete when the plan was supposed to be done.
Another thing about estimation that many people seem to overlook. The use of Story Points was not intended to say that all 8's are the same. It indicates that based on our current knowledge and past experience it is similar in nature to other stories we have worked on that were 8's. In reality some of those 8's were bigger than thought as work progressed. But there were also many of them that turned out to be much smaller as work progressed. The more a team does this the better their ability to estimate evolves. And their interpretation of an 8 in Sprint 3 will most likely not their interpretation of an 8 in Sprint 18.
I think this would be the first thing I tried to get people to understand. It seems to be the basis of your problems and could probably have significant impact all around. I gave one example above. Another one I use is analogy to forecasting weather. When I was a kid in the 70's the weather forecasts were not great. They would forecast rain in 2 days and in reality we had a hot dry day for weeks. When I got into college in the mid-80's I took a meteorology class as an elective. It gave me some insights into the practice and I started to notice that the weather forecasts were more likely to be correct because of gathered knowledge and improvements in technology. Fast forward to today and meteorologist are now able to pretty accurately predict rain and temperatures to the hour for almost anywhere in the world. The longer you do the practice of forecasting, the better your accuracy becomes.