EPIC Creation
Hi All,
To give you all a background of the project I am a Scrum master for, there are 4 tools/apps that we are taking care of, with 3 full-time developers, 1 tester, and 1 product owner. Now, the PO has logged stories for all the 4 apps in backlog and shuffles between them as per the priority with the business.
My senior management has raised concerns about the way we have been using/creating EPIC in our storyboard. They say that we should have only 4 epics, 1 each per tool however that doesn't make sense to me because the way I understood it that EPIC is a larger story/feature that then gets broken down into sub user stories. I agreed that we may have created epic at a very granular level, however, I don't agree with 1 epic per tool concept. Just needed to get an idea, how they should be created.
Any input is appreciated.
Thanks
Is the development team comfortable by splitting their focus on 4 different apps each iteration? Is the product owner wishing for a potential releasable piece of software for each app every iteration? Is the product owner comfortable to prioritize backlog items for more than one app in the same backlog? Why is the senior management telling you to work?
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
As a Scrum Master your role is to make sure your senior management understands Scrum and to maximize the value created by the Scrum Team. The Product Owner's role is to maximize this value to the users as stated in the Scrum Guide:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
They say that we should have only 4 epics, 1 each per tool
Would those "epics" tell a coherent narrative story about how users receive value?
If not, it might be better to think of each tool as a product in its own right or perhaps as a separate theme. This could depend upon whether value ought to be released for each tool independently of the others.
Why is Senior Management interested in your use of epics? What need of theirs isn't met with your current situation? What do they think would improve if you moved to four epics?
@Mathieu
"Is the development team comfortable by splitting their focus into 4 different apps each iteration? Is the product owner wishing for a potential releasable piece of software for each app every iteration? Is the product owner comfortable to prioritize backlog items for more than one app in the same backlog? Why is the senior management telling you to work?"
PO's usually prioritize 2 tools per sprint. We don't take stories that involve more than 2 tools per sprint. The 4 tools are not that big a tool hence we have made a single product backlog for them. We are currently running with Sprint 4 and are able to deliver release s/w changes to the tool(s) in every iteration without any issue. We have also suggested, picking one tool for a couple of sprint in continuation in order to be more productive and focus. However, this is still under discussion.
I am the only one trained in SCRUM as of now. I am new to this and the senior management involvement is required to make sure that we are on track and doing things in SCRUM fashion, as much as possible. When they saw how we had created the EPIC, they mentioned they were too granular, which I agreed because indeed that was the case. But they wanted to create 1 epic per tool so that it would be easy for them to see how many story points have been taken up so far from each tool perspective.
It also depends on the tool you are using to manage your backlog. For instance in JIRA you could also choose a project and add labels... Which could accomplish what the management needs while allowing epics to be what they should.
@Aarti
Whatever the name given to a requirement, an "epic" or something else, the outcome should bring value to the users and be potentially releasable at the end of an iteration.
If all members of the Scrum team are comfortable with how the requirements are written right now, does the focus should be targeted to improve something else that brings more value by and for the Scrum team than the management?
In my own opinion, and like Filip previously wrote, it is probably more something related to the tool to manage the product backlog than a Scrum-related need.
I am the only one trained in SCRUM as of now. I am new to this and the senior management involvement is required to make sure that we are on track and doing things in SCRUM fashion, as much as possible.
I am perhaps making an assumption here, but based on this statement, Senior Management has not only been trained, but also has experience working in Scrum; hence the deference to them to coach others regarding Scrum?
By the way, what does your Product Owner think of all that? After all, he is in charge of Product Backlog Management.