Amazing Apps User Group

227 Members

Join now

Sign in with your Microsoft Power Platform Community account

If you don’t have a Community account, you can create one.

Share group

Location

Brisbane Queensland, Queensland, Australia

Details

Welcome to the Amazing Apps User Group: the global community of practice for building enterprise Power Platform and Dynamics 365 apps with Scrum. Hosted by 14x Microsoft MVP and Scrum coach Neil Benson from Customery. UG ID:7405

Group leaders

danikahil, Neil Benson

Topics

Power Platform

Discussion

Join the group to participate in the discussion.

WrayMedia 19 on

Like (0)

Hi all,

I'm working on an education solution which will reduce the amount of time needed for an examiner to conduct 121 interviews with students. Typically these can take one to two hours.

The intention is to replace the time the examiner spends with the student initially and focus only on answers that the student did not answer well enough.

I have a collection of existing interviews with written reports on how well the student did on each question for training.

I see the process as follows:-

- Pose a series of questions to a student in a linked video.

- Record their responses in video.

- Use Azure Video Indexer (or similar) to extract a transcript of the student's answers

- Use Copilot to reference the answers against previous answers that have additional information about the quality of response. E.g. the student mentions the correct topics.

- Create a report that tells the examiner which questions the student did well on and which ones need attention.

- Link to video of each question.

- Examiner meets the student to only discuss the problem questions.

Any thoughts or suggestions would be appreciated.

Thanks

Richard

Show previous comments

Neil Benson 18 on

Like (2)

Hi Agile Apps builders! Happy new year.

I've created a January networking event and 11 placeholder events for our 2022 calendar. Each month, I've alternated between mornings and evenings to give everyone from every time zone an opportunity to attend events this year.

I've love your ideas for topics or speakers. I'm hoping to line up some panellists for DevOps, agile testing, selling agile, and agile certifications. What else would you like to know more about? Do you want to dive into agile frameworks like Kanban, Scrumban, SAFe, or Extreme Programming? Reply here and let me know or email agileappsug@customery.com.

Keep sprinting!

Show previous comments

Neil Benson 18 on

Like (1)

What practice does your team primarily use for capturing requirements?

Functional requirements specifications
Use cases
User stories
Something else

Would love to know what your team uses and why.

Show previous comments

Neil Benson 18 on

Like (0)

Hi MorajkarPreeti, thanks for your question. I'm meeting up with @Dani this week and he's an expert at managing requirements in agile projects. We'll record a video or podcast episode answering your question and post it back here in a few days.

MorajkarPreeti on

Like (1)

Hello Neil,

My team currently uses user story.

But we are struggling to break long duration projects such as Translations, ERP integrations etc into user stories.

Can you please share any case study for such huge requirements in dynamics crm where how features, user stories and broke to work in small sprint such as 2 weeks.

Also secondly when sprint end and build is given for UAT , how development team is working on another sprint in case of crm?

Neil Benson 18 on

Like (0)

I'm running a LinkedIn poll to help prioritise topics for an upcoming 'Ask Me Anything' series of workshops. Let me know what topics you'd like to dive into, or suggest new ones, in the poll: Post | Feed | LinkedIn

Show previous comments

markrowbottom on

Like (0)

Just had an interesting experience and this may be my 'waterfall' based thinking as I'm only recently getting involved in more agile projects. A member of the Dev team has been really struggling with a reasonably complex flow as part of a user story. It was originally estimated at a few hours but has taken days and still not working correctly (my issue with the Dev team estimation is likely going to be the topic for another post!). When discussing this with the developer it became apparent that no design or preparation had happened prior to starting build. A review of the user story and acceptance criteria, then straight into build.

To me, and again 20+ years waterfall, < 1 year SCRUM....this feels wrong, it feels like using agile as an excuse not to build properly with full understand of what needs building. Flow can be a fickle beast and I'd have expected a Visio or flow diagram showing the logic etc before starting build. I'm not expecting war and peace design document but I don't see how you can build out a user story in power platform (especially flow) without some kind of planning/design before starting build?

I'm I missing the concept? I'm struggling with the team at the moment and I don't want to enforce bad practice if I'm misunderstanding a vital agile/SCRUM concept.

Mark.

Show previous comments

Neil Benson 18 on

Like (0)

Hi Mark, if I was coaching this team as a scrum master, there are a couple of themes I would try and help the team explore:

Did we know it was a complex flow before forecasting we could do it this sprint? If so, is there any way we could have split this backlog item into smaller ones?
Did the developer who picked up this sprint backlog item raise it as an issue in the next available daily scrum to make it transparent to the team that the item was more complicated than originally anticipated? I get the sense from your post that the developer held on to it for 'days'. Why was that?
Does your team use the 'definition of ready' practice? If you often have issues with items like this one, then this might be a technical practice you want to explore further. (See 'Sprint Backlog Proven Practices' video in my Scrum for Microsoft Business Apps course).
Why are we estimating in hours? When we estimate in hours, it's an absolute time estimate that doesn't take into account hidden complexity in the requirements or the ability of the developers who will work on it. This is one of the reasons why I prefer estimating in an abstract unit like story points. Estimating in story points is like estimating a trail run in kilometres, whereas estimating a trail run in hours doesn't take into account the speed of the runners.
When the team estimated the size of the backlog item, did they have an agreed design in mind? A sketch or description of the design probably would have helped here. Doesn't need to be a full-blown specification, but a page or two might have uncovered any hidden complexity before development started. If we don't have an agreed design in mind, then we're guessing, not estimating.